6 ms·
> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved
by dirtyaura 15y ago
> 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.
- raleec 15y agoAnd 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..
- roel_v 15y agoYes, very correct! I hope the 'lets just use Unix timestamp because it's easy' mentality will go away soon!
- peteretep 15y agoWhat would you replace it with for storing a single date?
- roel_v 15y agoDepends 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.
- dirtyaura 15y agoUTC 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.
- wladimir 15y agoUnix 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.
- Gonsalu 15y agoThere 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.
- dirtyaura 15y agoUTC 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.
- peteretep 15y agoUTC 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?
- dirtyaura 15y agoMaybe 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.
- derobert 15y agoActually, 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 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.
- jrockway 15y agoThe 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?
- eru 15y agoAs 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.
- angstrom 15y agoAnd 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.