TZ change in day causing date to change
gauteh opened this issue · comments
A corner case for sure, but it is possible to change date by changing timezone (https://docs.rs/chrono/0.4.7/chrono/offset/trait.TimeZone.html#method.ymd). I do not think this is handled by the format currently.
Can you elaborate on this a bit, please? Quoting the page you're linking to:
The time zone normally does not affect the date (unless it is between UTC-24 and UTC+24)
I don't think we'll have timezones with an offset of 24 hours or more, since the TZ directive is supposed to only accept tz database time zone names, and I don't think it contains any definitions with an offset that large, except maybe for historical entries.
But still, it's being "handled". I've already put some thought into this, but have not yet written it down. Basically, specifying a date in the input file should make all timestamp lines that come after it use that as their date, verbatim, without even thinking about timezones. This is rather intuitive in an example like this:
TZ Europe/Berlin # on this day (with DST) equivalent to UTC+2
2019-07-26:
0330 secret teleporter experiment
TZ America/Godthab # Greenland, UTC-2
0015 tidy up secret lab after teleporter experiment # this is 45 minutes later
It's not so intuitive when you travel across dates backwards:
TZ America/Godthab # still UTC-2
2019-07-26:
2330 teleporter experiment, return trip # i.e. 2019-07-27 01:30 UTC
TZ Europe/Berlin # UTC+2
0415 tidy up Berlin secret lab # will cause an error, because this is 2019-07-26 02:15 UTC, i.e. earlier than the previous entry
- The
2330line is prefixed by the previous date line (2019-07-26), and the resulting datetime is interpreted to the timezone of the2330line:2019-07-26 23:30 UTC-2aka2019-07-27 01:30 UTC. - The
0415line is prefixed by, again, the previous date line (2019-07-26), and the resulting datetime is interpreted to the timezone of the0415line:2019-07-26 04:15 UTC+2aka2019-07-26 02:15 UTC.
In other words, the wall clock in the Berlin secret lab said 04:15, and you were right to enter that local time into the file, but in Berlin it's already the 27th and so you need to add a 2019-07-27: line before your entry.
Let's revisit the first example for a curious case. Suppose you've started your teleporter experiment an hour earlier:
TZ Europe/Berlin # UTC+2
2019-07-26:
0230 secret teleporter experiment # 26th, 00:30 UTC
TZ America/Godthab # Greenland, UTC-2
2315 tidy up secret lab after teleporter experiment # 27th, 01:15 UTC
By not entering the local date in Greenland, you've now made your 45 minutes time entry 24 hours and 45 minutes long. The correct solution would be this, even though it looks as if you're traveling back in time:
TZ Europe/Berlin # UTC+2
2019-07-26:
0230 secret teleporter experiment # 26th, 00:30 UTC
TZ America/Godthab # Greenland, UTC-2
2019-07-25:
2315 tidy up secret lab after teleporter experiment # 26th, 01:15 UTC
Does that make sense? My goal is to keep the amount of "magic" when parsing the file as low as possible, therefore no date calculations or conversions should happen when changing timezones in the middle of a file.
Hm, I guess I have to think a bit more about this. I am not totally clear about whether there will be an ambiguity when crossing backwards through DST in the same time zone as well, but I need to look into this more. I am experimenting with a rust implementation, and I have just started to consider timezones. Also, the first non-comment/non-empty line of a timesheet file must be a TZ line?
Also, the first non-comment/non-empty line of a timesheet file must be a TZ line?
Not exactly, no, but there must be a TZ line before the first timestamped line, because that's when we need some timezone information, and imho relying on the system's local time is a bad idea.
I guess I should really put some effort into #17, right? I can continue on it no earlier than the 1st of August though.
Right, yes. Otherwise the time might change. No rush :)
This timesheet has, as far as I can see, an ambiguous time entry:
TZ Europe/Oslo
2019-10-26:
0900 good morning
1500.
2019-10-27:
0100 up early today
0230. # going to sleep (this time happens twice on this day!)
the last stop time 0230 happens twice on this day in this time zone so it is not possible for the parser to know which timezone (CET or CEST in this case) to use.
Yes, that's a problem, and I've been thinking about it myself a few days ago, too. If we're using just a combination of tz database location strings and local timestamps, there's only one workaround: If you really have that case (which just occurs once a year, in the middle of the night), set TZ UTC and write your timestamp(s) in UTC to disambiguate.
That's ugly, I know.
I'm thinking of allowing another possibility: Allowing the user to specify timezone offsets, e.g. TZ +02:00, explicitly. No automatic DST handling would occur whatsoever. What do you think about that?
And yes, I've thought about allowing timestamp offsets for a single line, too, like 1234+0200 foo, but I'm not sure about it. This may introduce issues regarding how to reference these lines, see also #14 (comment).
Edit: The special TZ format I've mentioned should imho support the RFC 3339 time-offset format, but (for consistency with our timestamps) with the colon being optional i.e. as a regex [+-]?\d{2}:?\d{2}. The special values UTC and Z should also be supported, both meaning UTC.
It is a corner case, for sure. So although it must be handled it does not need to be extremely short and easy to use, but just really explicit. I think having a HH:MM+TZ:TZ should be enough, if not even allowing for a full time stamp including date, TZ and DST flag. I think it is nice to be allowed to work in timezone rather than fixed offsets for the user at least, but you could leave that convenience to the implementation.
As far as I am aware the timezone Europe/Oslo cannot contain DST information? So just adding a new TZ Europe/Oslo DST line before that line is not possible?