Bug #1230

flt.utils.trimmer: local time can be nonexistent or ambiguous with DST

Added by Philippe Proulx 4 months ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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:

  1. When you specify 2019-03-10 2:30 to mktime(), it returns a timestamp which, converted back to a local date/time, is 2019-03-10 3:30 (with DST). I believe this is unexpected and a completely arbitrary decision.
  2. When you specify 2019-11-03 1:30 to mktime() and set the tm_isdst member to -1, it returns a timestamp which, converted back to a local date/time, is 2019-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:


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):


I hope GLib functions can detect that when you don't specify a time zone (local time).

Related issues

Related to Babeltrace - Bug #1229: flt.utils.trimmer: with no date, beginning time cannot be greater than end timeNew02/17/2020


Updated by Jonathan Rajotte Julien 4 months ago


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 4 months 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 4 months ago

  • Author changed from 215 to 22

Updated by Jonathan Rajotte Julien 3 months ago

Migrated from internal bug tracker.

Also available in: Atom PDF