Re: DateTimeZone silently falls back to UTC when providing seconds
| From: | Andreas Heigl | Date: | Sun, 12 Sep 2021 11:06:05 +0000 |
| Subject: | Re: DateTimeZone silently falls back to UTC when providing seconds | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116034@lists.php.net to get a copy of this message | ||
Hey Benjamin, Hey All
On 11.09.21 23:58, Benjamin Morel wrote:
Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0xA8D5437ECE724FE5.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc
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 exampleHi, 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?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 — BenjaminNo need. Early timezone offsets in the timezone database are in LMT (local mean time), which have second granularity. cheers, Derick
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
|
+---------------------------------------------------------------------+
Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0xA8D5437ECE724FE5.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc