Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

[Andreas Heigl]

Hey

On 13.09.21 13:32, Hans Henrik Bergan 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

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







So my question still stands:



Again: Just my 0.02 €

Cheers

Andreas

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". 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! What use-case does it serve to allow offsets that are not reflected in the TZDB? * That almost happened some years ago. IIRC the government actually postponed the change so the TZDB and all the upstream vendors could react.

On Sun, 12 Sept 2021 at 13:06, Andreas Heigl <andr...@heigl.org> wrote:

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:andr...@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:andr...@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+

OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature