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:30tomktime(), 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:30tomktime()and set thetm_isdstmember 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).
Updated by Jonathan Rajotte Julien almost 5 years ago
Follow-up:
From Simon Marchi:
I agree that this is not so good, but it's also quite an edge case that won't be easy to solve. For starters, the iso8601-related functions appear to be able to parse an arbitrary number of digits for sub-seconds, but in the end seem to store the value with a microsecond precision (e.g. g_date_time_get_microsecond), which is not enough for us (I assume we want to go to nanosecond). Implementing support to detect non-existent or ambiguous times would be a huge time sink with not so much value. Can it stay as a known problem in the initial release, and we revisit it in later versions if needed?
From Jonathan Rajotte:
We will revisit this later on. Not a priority.
Updated by Jonathan Rajotte Julien almost 5 years ago
- Related to Bug #1229: flt.utils.trimmer: with no date, beginning time cannot be greater than end time added
Updated by Jonathan Rajotte Julien almost 5 years ago
- Author changed from 215 to 22
Updated by Jonathan Rajotte Julien almost 5 years ago
Migrated from internal bug tracker.