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

31–40 of 96 posts

Re: How to save datetimes for future events

#31

Post by abfan1127 »

laut wrote: post #17
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.

sorry, thats what I meant by the software (change its ability to understand the rules). IANA link is helpful!

Re: How to save datetimes for future events

#32

Post by kbenson »

mark-r wrote: post #28
kbenson wrote: post #26

This comes from mismatched expectations of what users are storing. Often they think, or assume without thinking, that they are storing a localized time. For ease of implementation, or just because the developer doesn't know any better, we often store in absolute time (UTC) with an offset and call it done. The problem is, nobody really thinks about this stuff. It's easy to pick out an error case and say "The users exp…

If you stored it as your local time, it would be wrong. If you stored it as Chile's local time, it would be correct. The trick is to simply record the appropriate time zone along with the timestamp.

Absolutely correct. I was thinking that, even if we words said something else. :/ I've updated the last paragraph to reflect that.

Re: How to save datetimes for future events

#33

Post by abfan1127 »

mark-r wrote: post #22
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?

The example is perfect. It isn't enough to change the software, you must also change the existing data, because with the rule change it is now wrong. Or you can take the advice and store your data in a form that doesn't become obsolete when the rules change.

If you store it in UTC, it becomes obsolete when the rules change for that location. If you store it in the local time, it becomes obsolete for other timezones (think the timezone of the traveler before they leave). If you store both UTC and the local, then one (of the 2) becomes obsolete, but recoverable assuming you can scrub the data. However, you must know which is correct based on the rules change itself.

Re: How to save datetimes for future events

#34

Post by dragonwriter »

mark-r wrote: post #25
sangnoir wrote: post #18

Earlier quoted context omitted.

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

Why would the time for the Australian be incorrect? If the meeting organizer is in Chile, then the meeting time would be ruled by Chile's local clock. If the rule change affects the difference between Australia and Chile, then simply loading the updated rules on both sides should readjust things automatically - if the time was stored as Chile local, not UTC.

The fact that the meeting organizer in Chile does not imply that the key constraint for the meeting time was in Chile, rather than in the schedule of the Australian attendees.

(Of course, its actually possible that there were essential constraints on both sides, in which case, the problem is more difficult, or that the key constraint was that the call needed to immediately precede or follow an event in a timezone different from Australia or Chile.)

Really, determining the key intent here is hard, and there is no one rule that makes it painless in all cases. There are lots of different possible intents with timing, and there is no single general rule that handles all possible changes in local time rules between the time an event is scheduled and the time it occurs.

Re: How to save datetimes for future events

#35

Post by ska »

This doesn't really seem to solve the problem, just makes some of the error modes less surprising to the user.

Surely the right approach to handling scheduling like this is (sticking with the calender example) a) initiating calender event is canonical (but may or may not be in the calenders local timezone) , but b) metadata about when the schedule was made and last updated is stored, and c) every future computation takes this metadata and looks up canonical (i.e. IANA) timezone/change information every time it touches the event, and d) a warning is given to any user, at any time their localization has a change in rules that might affect their apparent wall time, plus e) any changes in the localization of the initiating/owning calender trigger a warning for everyone.

Am I missing something? [edit: besides the way to format this list...]

(added - I should have been more clear that the server is only responsible for keeping track of the canonical event and updating clients if and when that changes. The clients will always be responsible for resolving locally apparent changes)

Re: How to save datetimes for future events

#36

Post by laut »

padobson wrote: post #19
laut wrote: post #13

Earlier quoted context omitted.

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?

Good question!

It is optional to store the UTC offset. The reason to store the UTC offset is to avoid ambiguity there might be when the timezone rules do not change.

If the timezone rules don't change and you happen to be storing a datetime that is during changing from DST to non-DST, you specify which specific time you are talking about. In autumn, clocks could be set back from 3:00 to 2:00. 2:30 happens twice. When you schedule the time you can ask the user "2:30 summer time or 2:30 winter time"?

So you only use the offset for anything in rare case there is an ambiguity (usually because of going off of DST), otherwise you just ignore it. In most cases even if the rules change like in the Chile example you would ignore it as well and use the offset provided by the timezone database.

Re: How to save datetimes for future events

#37

Post by philh »

sangnoir wrote: post #18
laut wrote: post #15

Earlier quoted context omitted.

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

Yeah, it seems like there's no general solution to this. If I put in '10AM in Chile' for grabbing coffee with a friend, I probably want it to stay in wall time no matter what happens to the offset.

If I'm making a note of a solar eclipse, I need it to stick with physical time, and if the offset changes the reported time changes.

If I'm scheduling a conference call to Australia, then when the offset changes, one of us is going to have to reschedule, and my calendar can't know which. (We might both have to reschedule, if neither of us can move it by a single hour.)

It might be able to say "you scheduled this at 10AM, but the DST rules changed, and that physical time is now 11AM wall time, what to do?" My Australian colleague isn't going to get that warning, unless her calendar knows that she's talking to someone in Chile, but as long as one of us knows about the problem, we should be okay. But I'm not sure I trust this to cover all bases.

Re: How to save datetimes for future events

#38

Post by logicuce »

protomyth wrote: post #30

For future events, you expect to schedule a meeting / appointment at [Local Time] on [Date] at [Location]. If a time change happens between now and the future event (e.g. daylight savings time), it doesn't matter from the perspective of the meeting because you have a fixed time. So, I would for future events record [Local Time], [Date], and [Location]. Then make sure I have a [Location] -> [Time Zone] table. [Local T…

Spot on. You don't need the UTC at all to be stored. What matters is the local time at the venue.

If its a virtual meeting (eg. over Skype) with participants from multiple time zones, it is safe to assume always one time zone will take precedence over others and time should be saved with respect to that.

If its a natural event like a solar eclipse, it can be saved in UTC.

There is always one time zone in which the event won't be adjusted. Just use that.

Re: How to save datetimes for future events

#39

Post by kbenson »

ska wrote: post #35

This doesn't really seem to solve the problem, just makes some of the error modes less surprising to the user. Surely the right approach to handling scheduling like this is (sticking with the calender example) a) initiating calender event is canonical (but may or may not be in the calenders local timezone) , but b) metadata about when the schedule was made and last updated is stored, and c) every future computation t…

Yes, whether the location/context of the event is relative to you or some other location. I.e. Someone outside Chile creates an event to track the start of a football game in Chile before the change mentioned in the article.

What you really want is an absolute time, and a localized timezone that applies to the event (which may not be your own).

Re: How to save datetimes for future events

#40

Post by ska »

kbenson wrote: post #39
ska wrote: post #35

This doesn't really seem to solve the problem, just makes some of the error modes less surprising to the user. Surely the right approach to handling scheduling like this is (sticking with the calender example) a) initiating calender event is canonical (but may or may not be in the calenders local timezone) , but b) metadata about when the schedule was made and last updated is stored, and c) every future computation t…

Yes, whether the location/context of the event is relative to you or some other location. I.e. Someone outside Chile creates an event to track the start of a football game in Chile before the change mentioned in the article. What you really want is an absolute time, and a localized timezone that applies to the event (which may not be your own).

Ah, I wasn't clear enough ... I was thinking in that case the canonical calender event would be encoded in time in Chile, even if the local calender was in Germany or whatever. Looking back that could have been written much better so I've added a parenthetical.
Post reply on HN