# DateTimeZone silently falls back to UTC when providing seconds - Thread: https://externals.io/message/114669 - Original archive: https://news-web.php.net/php.internals/114669 - Started by Benjamin Morel on 2021-05-30T21:45:12+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #114669 — Benjamin Morel — 2021-05-30T21:45:12+00:00 URL: https://externals.io/message/114669#114669 Hi internals, An issue 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 --- ## #114670 — Derick Rethans — 2021-05-30T22:10:21+00:00 URL: https://externals.io/message/114669#114670 · In reply to: #114669 >Hi internals, > >An issue 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? --- ## #114671 — Benjamin Morel — 2021-05-30T22:18:31+00:00 URL: https://externals.io/message/114669#114671 · In reply to: #114670 > > 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 --- ## #114672 — Derick Rethans — 2021-05-30T22:32:51+00:00 URL: https://externals.io/message/114669#114672 · In reply to: #114671 > > […] > > >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 --- ## #116030 — Benjamin Morel — 2021-09-11T21:58:32+00:00 URL: https://externals.io/message/114669#116030 · In reply to: #114672 > > > […] > > 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 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 --- ## #116034 — Andreas Heigl — 2021-09-12T11:06:05+00:00 URL: https://externals.io/message/114669#116034 · In reply to: #116030 Hey Benjamin, Hey All > > […] > > > Hi, sorry for resurrecting an old thread, but now that this bug > 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 | +---------------------------------------------------------------------+ --- ## #116035 — Hans Henrik Bergan — 2021-09-13T11:33:09+00:00 URL: https://externals.io/message/114669#116035 >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 wrote: > > […] > > 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 > > > > > […] --- ## #116036 — Andreas Heigl — 2021-09-13T12:06:23+00:00 URL: https://externals.io/message/114669#116036 Hey > > […] > > 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. > > > > > […] > -- ,,, (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 | +---------------------------------------------------------------------+ --- ## #116037 — Pierre — 2021-09-13T12:26:39+00:00 URL: https://externals.io/message/114669#116037 · In reply to: #116036 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