Project

General

Profile

Actions

Bug #1230

open

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

Added by Philippe Proulx over 4 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
flt.utils.trimmer
Target version:
Start date:
02/17/2020
Due date:
% Done:

0%

Estimated time:

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:

  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:

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


Related issues 1 (1 open0 closed)

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

Actions
Actions #1

Updated by Jonathan Rajotte Julien over 4 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.

Actions #2

Updated by Jonathan Rajotte Julien over 4 years ago

  • Related to Bug #1229: flt.utils.trimmer: with no date, beginning time cannot be greater than end time added
Actions #3

Updated by Jonathan Rajotte Julien over 4 years ago

  • Author changed from 215 to 22
Actions #4

Updated by Jonathan Rajotte Julien over 4 years ago

Migrated from internal bug tracker.

Actions

Also available in: Atom PDF