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
