DateTimeZone silently falls back to UTC when providing seconds

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

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

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:

1. 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.

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