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

41–50 of 96 posts

Re: How to save datetimes for future events

#41

Post by kevin_thibedeau »

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.

There is still the problem of handling the effects of DST on repeating events. You have to know the base UTC offset and any additional seasonal offset for the local zone. Then it becomes an issue if you travel to a different locality that doesn't observe DST.

Re: How to save datetimes for future events

#42

Post by pimlottc »

sangnoir wrote: post #24
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.

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?

The Berliners should have the meeting entered in their calendar as 10 AM Chilean time. At any given moment when the meeting time must be evaluated or displayed on their own calendars, it can be converted to European time using the current time zone conversion rules.

Re: How to save datetimes for future events

#43

Post by laut »

sangnoir wrote: post #24
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.

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?

In the example in the blog post the meeting takes place in Chile, so Berlin time is irrelevant.

But let's say you are arranging a conference call between someone in Chile and someone in Berlin. When you arrange the meeting you have to define when the meeting takes place. So you have to choose a time zone along with a time for when the meeting starts. You could choose UTC, Berlin or Santiago. But you have to choose one.

Re: How to save datetimes for future events

#44

Post by protomyth »

logicuce wrote: post #38
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 ev…

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

I agree with everything except I would modify that statement to be "There is always one location in the which the event won't be adjusted. Just use that."

It seems like people are assuming time zone is fixed when it can change. The fixed point is the location which is used to determine the time zone.

Natural events are trickier because they have different assumptions than human created events. UTC is probably best for those.

Re: How to save datetimes for future events

#46

Post by curun1r »

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…

The problem with your solution is that while it solves the client-side of the equation, it creates a nightmare on the server-side. Imagine I need to send a reminder email to people an hour before their event. I now need to convert every saved time to the time on the server to know when to send that email. And I can't efficiently query the store of events since they're not stored in a uniform time format.

I'd rather handle edge cases like the story covers explicitly rather than have to deal with all the problems that result from storing times in a heterogenous fashion. I'd rather move the burden for this to the timezone libraries. What's being pointed out is that timezone conversion isn't a two-input function that takes a UTC time and a destination timezone. It's actually a 3-input function that takes those two arguments and an additional timestamp which is the date when the conversion should take place.

Re: How to save datetimes for future events

#47

Post by icebraining »

mark-r wrote: post #27
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.

That doesn't sound simple for the user at all. If I'm meeting locally with friends to see the game/oscars/wtv, I don't know or care about the time in the original timezone. My local TV guide / newspaper shows it in local time, and that's what everyone in the meeting cares about, so why would I set it to a completely different TZ?

Re: How to save datetimes for future events

#48

Post by baddox »

> Instead of saving the time in UTC along with the time zone, developers can save what the user expects us to save: the wall time. Ie. what the clock on the wall will say.

That's not at all foolproof, although it works for the case the author describes and probably works for most people most of the time. It wouldn't work if, for some reason, I'm entering a calendar event for something I know will happen exactly n hours from now.

Re: How to save datetimes for future events

#49

Post by protomyth »

curun1r wrote: post #46
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…

The problem with your solution is that while it solves the client-side of the equation, it creates a nightmare on the server-side. Imagine I need to send a reminder email to people an hour before their event. I now need to convert every saved time to the time on the server to know when to send that email. And I can't efficiently query the store of events since they're not stored in a uniform time format. I'd rather h…

"it creates a nightmare on the server-side"

Actually, last time I used something like this the queries aren't really that bad on a server (to write or execute). Its a fairly easy set of relational queries (build current time at location table -> events) and I would rather take the time on the server versus the client. This is the kind of thing a relation database does quite well and user expectations must be met.

Re: How to save datetimes for future events

#50

Post by VBprogrammer »

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.

Well, it has it wrong, depending on what you are using it for. If you are putting in a calendar entry for the next predicted Lunar eclipse storing them in anything but UTC is wrong.
Post reply on HN