Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to save datetimes for future events

creativedeletion.com

Post reply on HN
Print view View original

11–20 of 96 posts

Re: How to save datetimes for future events

#11

Post by x1798DE »

yourapostasy wrote: post #4

Would 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…

As pointed out in another post, the way timezone rule changes are stored actually does effectively what you are saying. For each time zone / locale, when there is a rule change, it is appended to the existing rules along with the date of the change. Example from the tzdata2015b file for the New_York time zone:

    # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
    Zone America/New_York	-4:56:02 -	LMT	1883 Nov 18 12:03:58
			-5:00	US	E%sT	1920
			-5:00	NYC	E%sT	1942
			-5:00	US	E%sT	1946
			-5:00	NYC	E%sT	1967
			-5:00	US	E%sT

Re: How to save datetimes for future events

#12

Post by stygiansonic »

yourapostasy wrote: post #4

Would 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…

I believe this is currently done, i.e. timezone databases track not only the current timezone information but store the valid dates for which a set of timezone rules apply.

This would be necessary not only for the example provided in the link, but also for larger changes, like several years ago when the US extended DST hours, and several other countries followed suit. (i.e. DST now begins on the second Sunday of March, rather than later in April)

Re: How to save datetimes for future events

#13

Post by laut »

igrekel wrote: post #10
laut wrote: post #5

Earlier quoted context omitted.

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 exam…

Author here. Yes, the error was to save any other time than the local time where the meeting is supposed to take place.

The point of the post was to demonstrate that when storing future events that is supposed to happen in a certain timezone, save the local time (along with timezone) instead of converting to UTC.

Re: How to save datetimes for future events

#14

Post by mark-r »

bickfordb wrote: post #3

Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats

That doesn't help if you don't save the time zone rules that were in effect when you converted the original timestamp to UTC. The problem is that you've already converted to UTC using the wrong rules, so to make things right you need to unconvert then reconvert again. But there's no way to know which timestamps need correcting and which ones don't.

The databases keep track of the zone changes so you can use the proper rules for conversions in the past. They don't protect you from changes in the future.

Re: How to save datetimes for future events

#15

Post by laut »

bickfordb wrote: post #3

Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats

Yes. But in this case the timeline is something like this:

1) You arrange a meeting 2) Then, after you have arranged the meeting, politicians/bureaucrats decide to change the time zone rules 3) Your meeting takes place

At 1) the rules are different from at 2). At 1) you cannot see into the future and anticipate how the rules will be at 2), because you don't have a time machine. So you have to be ready for it by implementing in a way that is resistant to timezone rule changes. For instance like the described solution.

Re: How to save datetimes for future events

#16

Post by mark-r »

igrekel wrote: post #10
laut wrote: post #5

Earlier quoted context omitted.

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 exam…

The problem is not naive software, the problem is that you can't predict the future. There will always be dates in the future that will be impacted by some rule change that hasn't been officially enacted yet.

Re: How to save datetimes for future events

#17

Post by laut »

abfan1127 wrote: post #6

It 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?

Author here. When the timezone rules change, the software updates its timezone database. This is how it should be. You don't have to change the software, the software should be able to handle the changes to the timezone database.

The updates are available here: http://www.iana.org/time-zones So far there has been two new releases of the database in 2015. Last year there were about 10 changes.

Re: How to save datetimes for future events

#18

Post by sangnoir »

laut wrote: post #15
bickfordb wrote: post #3

Don't most time zone databases store the date of rule changes? http://en.wikipedia.org/wiki/Tz_database#File_formats

Yes. But in this case the timeline is something like this: 1) You arrange a meeting 2) Then, after you have arranged the meeting, politicians/bureaucrats decide to change the time zone rules 3) Your meeting takes place At 1) the rules are different from at 2). At 1) you cannot see into the future and anticipate how the rules will be at 2), because you don't have a time machine. So you have to be ready for it by imple…

The prescribed solution does not solve for all use cases though.

Imagine if the meeting included a conference call to someone in Australia. A day before the meeting, the bureaucrats change the DST rule. The meeting invite for the Australian now has incorrect time. Storing as local time will work against events applicable across timezones.

The problem isn't with UTC, it is unexpected rule changes that the converting agent (software) did not predict. That logic will have to be coded in.

Re: How to save datetimes for future events

#19

Post by padobson »

laut wrote: post #13
igrekel wrote: post #10

Earlier quoted context omitted.

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 exam…

Author here. Yes, the error was to save any other time than the local time where the meeting is supposed to take place. The point of the post was to demonstrate that when storing future events that is supposed to happen in a certain timezone, save the local time (along with timezone) instead of converting to UTC.

Why store the UTC offset too, then? Couldn't you get that with the timezone? Then you've got the wall time for the meeting saved, and if you need to convert it to UTC for some reason, you could do it with the most current rules for the timezone.

If the offset becomes meaningless in the event of a rule change anyway, why save it when the most current rules will help you get the offset?

Post reply on HN