Bug #1230
openflt.utils.trimmer: local time can be nonexistent or ambiguous with DST
0%
Description
In Canada, this time is nonexistent:
2019-03-10 2:30
This specific time does not exist because DST starts on 2019-03-10 2:00
(so the local time becomes 2019-03-10 3:00
, with DST).
This time is ambiguous:
2019-11-03 1:30
This time occurs twice because DST ends 2019-11-03 2:00
(so the local time becomes 2019-11-03 1:00
again, but without DST).
Currently flt.utils.trimmer
guesses times when you specify one of these:
- When you specify
2019-03-10 2:30
tomktime()
, it returns a timestamp which, converted back to a local date/time, is2019-03-10 3:30
(with DST). I believe this is unexpected and a completely arbitrary decision. - When you specify
2019-11-03 1:30
tomktime()
and set thetm_isdst
member to-1
, it returns a timestamp which, converted back to a local date/time, is2019-11-03 1:30
(with DST). This is also a completely arbitrary decision.
I am disappointed that mktime()
does not return an error with a specific code for what's happening in those situations.
To avoid such completely arbitrary decisions, we need a date/time format with which you can specify the time zone, or at least that for your local time zone, when the time is ambiguous, you want it on the DST side or not.
Simon Marchi suggested to use ISO 8601, as more and more of our tools use this standard, and GLib has functions to deal with this format. I also checked and it supports having nanoseconds (any number of digits in fact) after seconds (and even after minutes and hours), for example:
2019-05-01T18:52:47.192838473 2019-05-01T18:52:47.192838473-04 2019-05-01T18:52:47.192838473Z 18:52:47.192838473 18:52:47.192838473-04 18:52:47.192838473Z
All those are valid ISO 8601 date/times. I don't know if GLib can parse nanoseconds however; we could have to parse this part ourselves.
To fix issue 1 (2019-03-10 2:30
: nonexistent time), we need to detect that the time does not exist, instead of silently adding one hour, and fail (report nonexistent time).
To fix issue 2 (2019-11-03 1:30
: ambiguous time), we need to fail (report ambiguous time) and ask the user to specify the time zone to indicate if DST was ended or not, one of (for Canada):
2019-11-03T01:30-04 2019-11-03T01:30-05
I hope GLib functions can detect that when you don't specify a time zone (local time).