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

  116035
September 13, 2021 11:33 divinity76@gmail.com (Hans Henrik Bergan)
>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 > > On Sun, 12 Sept 2021 at 13:06, Andreas Heigl <andreas@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:andreas@heigl.org N 50°22'59.5" E 08°23'58" | >> | https://andreas.heigl.org | >> +---------------------------------------------------------------------+ >> | https://hei.gl/appointmentwithandreas | >> +---------------------------------------------------------------------+ >> >