Project

General

Profile

Actions

Bug #1230

open

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

Added by Philippe Proulx almost 5 years ago. Updated almost 5 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

Also available in: Atom PDF