How to save datetimes for future events • Hacker News Board

Re: How to save datetimes for future events

#21

Post by fryguy » Mon, Mar 23, 2015, 4:22 PM UTC

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 a good one, you are just misunderstanding what the problem is. Here is the synopsis:

1. User makes an appointment for 11am local time when he meets his friend in Chile. Using current timezone rules (GMT-3), the program saves this in the database as 1400 UTC. 2. Chile decides to change the rules for their time zone. Software gets updated with new table. Now, the appointment is at 10am local time in Chile, since they are GMT-4 now (1400 UTC = 10am GMT-4)

Re: How to save datetimes for future events

#22

Post by mark-r » Mon, Mar 23, 2015, 4:23 PM UTC

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.

Re: How to save datetimes for future events

#23

Post by fryguy » Mon, Mar 23, 2015, 4:24 PM UTC

Unfortunately, there's an ambiguity here. Suppose that you're going to watch the Super Bowl with your friends in Chile. So you set the appointment for 1830 local time in Chile. Then Chile changes their timezone, and your local time is wrong since the actual event is based on Eastern time, and not Chile time.

Re: How to save datetimes for future events

#24

Post by sangnoir » Mon, Mar 23, 2015, 4:26 PM UTC

laut wrote: post #5

VBprogrammer wrote: post #2

If 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.

Pegging against "wall time" in Chile causes it's own problems. What if the meeting is with a person in "Europe/Berlin" via Skype and the appointment is in a shared calendar. How would the new Berlin time be calculated for the unfortunate Berliner after the Chilean bureaucrats have had their fun?

Re: How to save datetimes for future events

#25

Post by mark-r » Mon, Mar 23, 2015, 4:27 PM UTC

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…

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.

Re: How to save datetimes for future events

#26

Post by kbenson » Mon, Mar 23, 2015, 4:28 PM UTC

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 expect local (relative) time, we need to deliver that." That's not always right. There are plenty of cases where the user really wants absolute time. Fro example, when scheduling an international meeting where the other side is dictating the time. When timing a broadcast from another country. Really, any time when you need to deal with events scheduled outside your local time, or have components (or people) that run on times that are not local to you.

It gets trickier. What if you are tracking that international event, and that locality changes their time rules? For example, what if I'm in the US, and I wanted to schedule a time to watch a sporting event in Chile, and I scheduled it before the changed mentioned in the article? Whether I store it as a local time or an absolute time, it's wrong.

Really, you need three pieces of information. The UTC time representation, the timezone offset it applies to, and whether it should be treated as an absolute or localized time.

Edit: Corrected what type of stored offset needs to be kept

Re: How to save datetimes for future events

#27

Post by mark-r » Mon, Mar 23, 2015, 4:30 PM UTC

fryguy wrote: post #23

Unfortunately, there's an ambiguity here. Suppose that you're going to watch the Super Bowl with your friends in Chile. So you set the appointment for 1830 local time in Chile. Then Chile changes their timezone, and your local time is wrong since the actual event is based on Eastern time, and not Chile time.

You simply need to observe the rule that event times should be specified in the time zone of the event itself.

If the event is a meeting, then the meeting organizer will be in charge of setting the appropriate time zone.

Re: How to save datetimes for future events

#28

Post by mark-r » Mon, Mar 23, 2015, 4:31 PM UTC

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.

Re: How to save datetimes for future events

#29

Post by laut » Mon, Mar 23, 2015, 4:33 PM UTC

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…

Let's say the meeting is supposed to take place at 15:00 "wall time" in Sydney on March 30th. Someone changes the DST rules. The meeting still takes place at the specified time. Remember we specify the time at Australia. So far so good.

Usually the time from a new update is released at least a week before the change takes place. So your software might alert you about the time on the same day or the day before of the meeting. Or even half an hour before. Do the calculations at that time of the alert with the newest timezone data. And if the software is up to date with timezone database changes, users in other time zones will be alerted about the correct time. The calculation will be made before the meeting from 15:00 Sydney to whatever other time zone someone might be in.

Re: How to save datetimes for future events

#30

Post by protomyth » Mon, Mar 23, 2015, 4:34 PM UTC

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 Time] and [Date] would probably be combined into one field. The crux of the problem is shifting rules on time zone (and location is my time zone determinant), so recalculation for other time zones is going to have to be dynamic. Storing UTC or UTC offset doesn't help the problem and actually creates a false solution.