Everything

php

DateTimeZone silently falls back to UTC when providing seconds

php.internals

Benjamin Morel

5 years ago

Hi internals,

An issue <https://github.com/brick/date-time/issues/35> was brought up on
my date-time library, that boils down to the fact that DateTimeZone
silently falls back to UTC when providing an offset with seconds:

(new DatetimeZone('+01:45:30'))->getName(); // 00:00

https://3v4l.org/9ZrK6

If this is unsupported (this would make sense), should it throw an
exception instead?

Thank you for your time.

⁠— Benjamin

Derick Rethans

5 years ago

On 30 May 2021 22:45:12 BST, Benjamin Morel <benjamin.morel@gmail.com> wrote:

>Hi internals,
>
>An issue <https://github.com/brick/date-time/issues/35> was brought up
>on
>my date-time library, that boils down to the fact that DateTimeZone
>silently falls back to UTC when providing an offset with seconds:
>
>(new DatetimeZone('+01:45:30'))->getName(); // 00:00
>
>https://3v4l.org/9ZrK6
>
>If this is unsupported (this would make sense), should it throw an
>exception instead?
>
>Thank you for your time.
>
>⁠— Benjamin

I can't think of why this couldn't work. Duke a bug report please at bugs.php.net?

Benjamin Morel

5 years ago

>
> I can't think of why this couldn't work. Duke a bug report please at
> bugs.php.net?

Before doing so, shouldn't we discuss whether it makes sense to accept a
time-zone offset with seconds, when the granularity seems to be 15 mins?

https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

— Benjamin

Derick Rethans

5 years ago

On 30 May 2021 23:18:31 BST, Benjamin Morel <benjamin.morel@gmail.com> wrote:

>>
>> I can't think of why this couldn't work. Duke a bug report please at
>> bugs.php.net?
>
>
>Before doing so, shouldn't we discuss whether it makes sense to accept
>a
>time-zone offset with seconds, when the granularity seems to be 15
>mins?
>
>https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
>
>— Benjamin

No need. Early timezone offsets in the timezone database are in LMT (local mean time), which have second granularity.

cheers,
Derick

Benjamin Morel

4 years ago

>
> >Before doing so, shouldn't we discuss whether it makes sense to accept
> >a
> >time-zone offset with seconds, when the granularity seems to be 15
> >mins?
> >
> >https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
> >
> >— Benjamin
>
> No need. Early timezone offsets in the timezone database are in LMT (local
> mean time), which have second granularity.
>
> cheers,
> Derick

Hi, sorry for resurrecting an old thread, but now that this bug
<https://bugs.php.net/bug.php?id=81097> has been fixed in PHP 8.0.10, I can
see that seconds have been forbidden from DateTimeZone altogether:

https://3v4l.org/QpSln

Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
(and going against JSR-310, which this library was derived from), can I
please know why this decision was made, when as I understand it, this goes
against your statement above?

Thanks in advance,
- Benjamin

Andreas Heigl

4 years ago

Hey Benjamin, Hey All

On 11.09.21 23:58, Benjamin Morel wrote:

>>
>>> Before doing so, shouldn't we discuss whether it makes sense to accept
>>> a
>>> time-zone offset with seconds, when the granularity seems to be 15
>>> mins?
>>>
>>> https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
>>>
>>> — Benjamin
>>
>> No need. Early timezone offsets in the timezone database are in LMT (local
>> mean time), which have second granularity.
>>
>> cheers,
>> Derick
>
>
> Hi, sorry for resurrecting an old thread, but now that this bug
> <https://bugs.php.net/bug.php?id=81097> has been fixed in PHP 8.0.10, I can
> see that seconds have been forbidden from DateTimeZone altogether:
>
> https://3v4l.org/QpSln
>
> Before forbidding seconds in brick/date-time's *TimeZoneOffset* as well
> (and going against JSR-310, which this library was derived from), can I
> please know why this decision was made, when as I understand it, this goes
> against your statement above?

For me the more interesting question is: "Why would one allow to create
any arbitrary Timezone-object using any offset at all?"

Currently it is even possible to declare a Timezone Object with an
Offset that has never been used anywhere on the globe. So for example
`new DateTimezone(`+11:32`) is completely valid from a coding point of
view but not from a timezone point of view. What use-case does that serve?

If one has to create a timezone-object for an existing timezone one can
create that either via `new DateTimezone('Continent/Whatever')` or via
`new DateTimezone('Etc/GMT+XX')` or via `new DateTimezone('PST')`.

This does currently not support creating offset-based timezone-objects
for areas such as Nepal or India that use an offset that currently can't
be declared via the `Etc`-Identifiers.

So a different approach would be to only support type 1 offsets that are
known to the TZDB. Everything else (including arbitrary seconds) should
result in an exception.

So I can understand to not allow arbitrary seconds at all. But IMO we
should then also not allow arbitrary minutes also.

But that's just my 0.02 €

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+