How to save datetimes for future events
creativedeletion.com
How to save datetimes for future events
1–10 of 96 posts
Re: How to save datetimes for future events
#2If I understand the objection here the problem isn't that the computer has the time wrong, it's that our understanding of time is wrong.
The computer still has the calendar entry at the right instant in time identified when the user input the entry.
Re: How to save datetimes for future events
#3Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats
Re: How to save datetimes for future events
#4Would it be possible to avoid any ambiguity at all by saving the timezone rules themselves as separate most-previous and current versions within the application context itself?
Then when a new set of rules is detected (perhaps notification of updates at the OS level should be turned into a standardized publish-subscribe API to avoid too many applications polling for changes all the time, especially wasteful on battery-powered devices), move the current version to the previous version, scan for timezone rule differences, then scan your collection of records that use those timezones, parse them down to only those records affected by the new rules, and finally apply corrections to those records affected by the new rules.
Extending further, if this approach works, perhaps an OS-level, perhaps git-backed storage of versions of timezone rules could avoid duplication of effort. Combined with a publish-subscribe service, it can auto-prune itself based upon the list of subscribed applications and when the oldest subscriber last hit the version store.
Re: How to save datetimes for future events
#5If I understand the objection here the problem isn't that the computer has the time wrong, it's that our understanding of time is wrong. The computer still has the calendar entry at the right instant in time identified when the user input the entry.
The problem is that the meeting time is defined in terms of the "wall time" in Chile.
So if you store the time in terms of UTC, then you are going to have problems when the relation between UTC and the Santiago/Chile timezone changes.
The computer in the example has the time wrong because it stored the time in UTC.
Re: How to save datetimes for future events
#6It seems that the example provided is a poor example. Software systems compute based on some rules. If you change the rules, you must change the software. Are there other more meaningful examples?
Re: How to save datetimes for future events
#7Would it be possible to avoid any ambiguity at all by saving the timezone rules themselves as separate most-previous and current versions within the application context itself? Then when a new set of rules is detected (perhaps notification of updates at the OS level should be turned into a standardized publish-subscribe API to avoid too many applications polling for changes all the time, especially wasteful on batter…
This post describes examples of ambiguity and non-existing times: http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
Note non-existing times mostly happen when you go from winter time to summer time. You set the clock ahead an hour at let's say 2:00 in the morning. So you go directly from 2:00 to 3:00. 2:30 does not exist.
So let's say that you plan a meeting at 2:30 in the morning in a country that does not use DST. Then they decide to use DST and set the clocks forward one hour at 2:00. Your meeting was supposed to take place at 2:30 local time, but that time no longer exists! As I see it, the right thing to do is to alert the user of the problem.
Re: How to save datetimes for future events
#8Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats
Yeah, this was always my understanding - time zones, DST participation and dates, etc all change more frequently than you'd expect, and time zone databases keep track of when things happen precisely for this reason. If that weren't happening, I think people would have found that many of their timestamps become obsolete / inaccurate relatively quickly.
That said, it does tie the stability of your datetimestamp to the stability of the tz database. I think that's a pretty good bet, but it's nice to be aware of where your abstractions can leak.
Re: How to save datetimes for future events
#9Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats
That's what I thought too. Based on the discussion surrounding this example[0], I believe that's the case.
Still, date/time is a tricky subject to get right.
0. http://stackoverflow.com/questions/6841333/why-is-subtractin...
Re: How to save datetimes for future events
#10If I understand the objection here the problem isn't that the computer has the time wrong, it's that our understanding of time is wrong. The computer still has the calendar entry at the right instant in time identified when the user input the entry.
The problem is that the meeting time is defined in terms of the "wall time" in Chile. So if you store the time in terms of UTC, then you are going to have problems when the relation between UTC and the Santiago/Chile timezone changes. The computer in the example has the time wrong because it stored the time in UTC.
If it was done properly, the target date in the future should be based on the UTC offset it will have at that time in the future before being converted to UTC for storage. The error is to convert to UTC based on the current UTC offset instead of the "political" timezone that would take in to account proper daylight saving changes.
There are problems when dealing with timezones and daylight saving changes but the example is just a case where the implementation was too naïve.