Hacker News Reader

Comment by dirtyaura | Hacker News Reader

> Timezones are a presentation-layer problem!

I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp.

The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event.

An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want to attent the meeting over Skype. When is it in London time?

It depends.

On 7 Mar 2011 it's at 5pm

On 14 Mar 2011 it's at 6pm

On 29 Mar 2011 it's at 5pm

To make these calculations, you need to know timezone & daylight saving time (DST) rules of both your current location and the home location of the event.

A "DST zone" of a home location of a repeating event has to be saved together with a time and thus it's not just presentation-layer issue.

View on HN

The article should add a caveat: use UNIX time when you are recording the current time to store for later use. That can always be formatted in the user's current timezone to display back.

When you're inventing a rule system based on local times, as you are above, of course you need to track the rules in the local time zone. That's because the rule is: "do this thing at 9am in my particular local time zone", not "do this thing every 86400 seconds". Keep in mind that this is hard, though, due to the fact that in many local time zones, one hour is missing on one day ("spring forward"), and one hour occurs twice on one day ("fall back"). If you have some event that should be triggered at 1:30am, which 1:30am do you mean? The first 1:30am or the second 1:30am? What about on the "spring forward" day, when 1:30am doesn't occur at all?

As an aside, have you thought about the effects of DST on train schedules? In Germany, for example, they literally stop the trains for an hour when the clocks go backwards and let them all run a nominal hour late when they are going forward.

Very interesting. I didn't realize that an hour made much of a difference to Deutsche Bahn's schedules, however :)

Sadly, not. And I've done some scheduling work for them.

And that doesn't even get into the problem of the DST dates changing at the whim of legislation like it did recently in the US about 5 years ago. If you are attempting to track timezone instead of UTC you've now have to check date ranges when different DST was in effect. Very messy stuff. Better to just keep it in UTC or Unix if you need the offset it was recorded in as you mentioned.

Talking of the DST point, how do you manage this in your apps? Say we're in the UK, you schedule something to run at 9am GMT. In the summer, the timezone changes to BST, so 9am GMT is still 9am UTC. I've never seen a scheduling app where you say 9am UK, and have it automatically switch GMT to BST. The closest I've seen is "use server time" where you have to setup the server to automatically apply the DST rules - but then you have issues when working with out of sync DST rules, such as those of the US.

Yes to everything stated above. We have a system that schedules events in the future, and the times are all wrong for a couple hours per year because the system is effecting DST @ 12:00am UTC instead of 2:00am local time! Getting time right in all cases is much more challenging than my people realize.

UTC is enough for - as the article suggests - storing a date.

Storing a recurring class of dates is - of course - more complicated; but then has anyone ever suggested otherwise?

Maybe nobody explicitly suggested otherwise, but I just wanted to highlight that time is a human concept and in informal context can mean a lot of different kinds of things (e.g. a time of recurring event). When you start formally modeling those, a single timestamp isn't enough.

Actually, UTC isn't enough for storing a date, at least not a date in the future. If I schedule a single event for 3pm on October 1 (currently in the future), I expect it to stay at 3pm. Even if my city hosts the Olympics: http://support.microsoft.com/kb/257178

Note also that not all governments are in the habit of giving sufficiently advance notice of daylight saving changes.

And not just for repeating events. I worked on an app that dealt with scheduling travel, and you needed to record the zone of both locales so that if a trip crossed time zones the trip length(which was derived) would remain accurate.

You also had to take into account what the DST would be for both locales at the scheduled time. Hint: Use Oracle, SQLServer doesn't have a way to stay updated with the constantly changing DST offsets worldwide..

There is no need to save the home location with the time.

If you save the UTC date of the event, the localized date for some timezone can be extrapolated from it.

UTC is enough if we have a single instance of an event. If we have a concept of recurring event ("this event will occur on every Monday 9am"), then it's not enough.

I just wanted to highlight that "time" is a human concept that in informal setting means a lot of things, but when you start to model it formally, it can be more complex than a single timestamp.

Yes, very correct! I hope the 'lets just use Unix timestamp because it's easy' mentality will go away soon!

What would you replace it with for storing a single date?

Depends on the context it's used in. Usually YYYY-MM-DDThh:mm:ss of ISO 8601, explicitly extend it with the UTC timezone (with the + notation), sometimes that plus the local timezone in a separate column/field, sometimes a serialized version of a library representation of a date.

UTC is fine for single events. For the recurring events, UTC + timezone alone is useless, you need to know the DST rules too to make correct calculations over the DST changes.

vCal has spec for DST rules, but you don't want to store them for every event. You store a location or "DST zone" of your event and have DST rules in separate database (they need to be updated as DST rules can change)

When I worked on calendar applications, there was not commonly agreed way to transfer DST zones between systems, but single DST rules could be transferred as part of vCal entry.

Microsoft apparently implemented their own integer code for every "DST zone" and used it to transfer events correctly between Microsoft systems (e.g. sending meeting invitations by email from Outlook to Outlook). Things might have changed since I worked on this area, I haven't checked the current status.

Unix timestamps are indeed easy and good enough for most cases (isn't the mantra "keep it simple"?), except for calendars/recurring events, as some people have pointed out.

Reply on news.ycombinator.com