DateTimeZone silently falls back to UTC when providing seconds

2 years ago by Benjamin Morel — view source

unread

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

2 years ago by Derick Rethans — view source

unread

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?

2 years ago by Benjamin Morel — view source

unread

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

2 years ago by Derick Rethans — view source

unread

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

2 years ago by Benjamin Morel — view source

unread

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

2 years ago by Andreas Heigl — view source

unread

Hey Benjamin, Hey All

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 |
+---------------------------------------------------------------------+

2 years ago by Hans Henrik Bergan — view source

unread

What use-case does that serve?

if some country want to change their timezone for whatever reason, to some
timezone that didn't exist previously, could happen at any time really

On Mon, 13 Sept 2021 at 13:32, Hans Henrik Bergan divinity76@gmail.com
wrote:

What use-case does that serve?

if some country want to change their timezone for whatever reason, to some
timezone that didn't exist previously, could happen at any time really
Hey Benjamin, Hey All

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 |
+---------------------------------------------------------------------+

2 years ago by Andreas Heigl — view source

unread

Hey

What use-case does that serve?

if some country want to change their timezone for whatever reason, to some
timezone that didn't exist previously, could happen at any time really

I'm well aware that that could happen at any time really. And I'm well
aware that "at any time" also can mean "By the way, we changed 14 days ago".

But what does that mean? That means that there are different possibilities:

The change was announced well in advance and therefore there is a
TZDB release that already reflects that change. So whatever timezone we
are talking about: The modification is already available and can be used
via the [continent]/[city] identifier. And if we would allow all
existing offsets to be used, that one would also be available.
The change was not announced well in advance, so that there is no
TZDB release that reflects that change when it goes "live". You PHP
application is the least concern you have. Because the change is not
reflected anywhere. Not on your server, not on your database, not on
the users mobiles not on the users desktops, not in their smartwatches:
nowhere.* Yes: You would then be able to allow people to enter the
offset instead of letting them comfortably select a location near them
and extrapolate the timezone (or offset if it must be) from that. But
you are then handling data that is not officially registered, could
possibly change and might break in the future due to some differences
that the official sources defined but your user didn't know about. That
is a rabbit hole that I would not want to get into and that we should
not encourage to get into. And which is currently open and seems to be
in need of fixing.

For completeness sake there is a further option: The change was
announced well in advance but you did not yet update your PHP-version or
the timezonedb pecl package. Do so! Preferably the former but if that is
not an option at least the later!

So my question still stands:

What use-case does it serve to allow offsets that are not reflected in
the TZDB?

Again: Just my 0.02 €

Cheers

Andreas

That almost happened some years ago. IIRC the government actually
postponed the change so the TZDB and all the upstream vendors could react.

Hey Benjamin, Hey All

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 |
+---------------------------------------------------------------------+

--
,,,
(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 |
+---------------------------------------------------------------------+

2 years ago by Pierre — view source

unread

Le 13/09/2021 à 14:06, Andreas Heigl a écrit :

Hey

What use-case does it serve to allow offsets that are not reflected in
the TZDB?

Yes there are use cases:

Your TZDB is obsolete, your hardware and OS is obsolete, but the
prod is still running (it happens more than you think).
You don't care about the TZ name and just use offsets (it happens
also, happened to me not so long ago I needed to convert dates with
arbitrary offset from some storage).
You fetch dates from a storage which doesn't care about time zone
names (hello any SQL database), for example pgsql doesn't store
offsets only UTC time, but it accepts arbitrary offsets as input,
regarding output dates converted to the explicitly asked time zone
or client connection time zone (so actually you this is not a valid
use case, but I wanted to highlight that pgsql accepts any arbitrary
offset).
You fetch broken dates with broken timezone from a broken storage,
but you have to deal with those dates one way or another.

There as many good reasons for accepting arbitrary offset that there are
offsets on each, so basically that 24*60 good reasons.

That's my opinion, as being confronted with dates problems quite often.

Just for fun, some pgsql random select:

db=# select timestamp with time zone '2021-09-13 14:24:00+03:15' at time
zone 'utc';
timezone

2021-09-13 11:09:00

Regards,

--

Pierre

DateTimeZone silently falls back to UTC when providing seconds

Andreas

Andreas

Andreas

db=# select timestamp with time zone '2021-09-13 14:24:00+03:15' at time zone 'utc'; timezone

db=# select timestamp with time zone '2021-09-13 14:24:00+03:15' at time
zone 'utc';
timezone