7 ms·
Why You Should Use Timezone Offsets Not Timezone Names
- thriqon 11y agoWhile I agree with your points when storing timing of (happened in the past) events, but I disagree when storing display preferences for the user. As a user, I do not want to change my timezone settings just because my country went into Daylight Saving.
- Xorlev 11y agoCame here to make the same point. Named timezones like America/Los Angeles are still important because they refer to both the timezone offset as well as the DST rules that govern that particular political zone. That being said, the gist of the post (time normalization) is obviously good. Stored time should always be UTC and converted for display later.
- wizardry90210 11y agoThe political realities of timezones is _exactly why_ you should be storing the timezone name if the user is scheduling it for an event in their local timezone. If a user is expecting an event to happen at 6pm in their local timezone, and political reasons cause that timezone's offset to change (ie. daylight savings), it will still happen at the correct local time for that user. Storing UTC offsets means that any future political changes will result in the wrong local times for users.
- lambda 11y agoI think the main thing to remember is that dates and times have very different semantics when used for different purposes. If you are referring to an instant in time, then just using UTC is reasonable. If you are referring to a past event and both the local time and precise instant are relevant, then the local time with a timezone offset is reasonable. If you are scheduling events on a calendar, however, like "8 AM every monday for the next four weeks", then yes, you need to store the abstract time zone name so that the calendar program can translate each instance of that schedule to the appropriate instant.
- kristiandupont 11y agoWhich is why you are both right: Offsets are good for past events, time zones for future ones. It's a real pain to deal with..
- bch 11y agoIf you're using the Olsen Database[0], aren't past (and future) changes all handled properly? [0] https://en.wikipedia.org/wiki/Tz_database https://en.wikipedia.org/wiki/Tz_database See: Example zone and rule lines
- kelnos 11y agoI suppose storing the offset is safer, because you have in a single string all you need to know to convert the time to UTC, but yes, that was my thought as well -- given a non-broken copy of tzdata, historical dates should be correctly convertible if all you have is a date/time and a timezone name.
- nvivo 11y agoStoring the offset won't work for future dates due to daylight savings changes.
- kelnos 11y agoTrue, but who cares? We're not talking about future dates, we're talking about recording a current timestamp, at which time we of course know the time zone and whether or not DST is in effect at that current point.
- Zarel 11y agoI wish they could at least store it in terms of the timezone name, like "Central Time". "America/Chicago" bothers me because I don't know what cities are and aren't in your timezone database. The ones that have a tiny map that you have to click on are also pretty bad.
- saurik 11y agoCST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.
- Zarel 11y agoMy bad, I'll update my comment.
- wtallis 11y agoAnd more commonly, EST doesn't mean just Eastern.
- kelnos 11y agoSure, but the parent didn't say "CST". For a user-facing interface, presenting random city names is terrible. "Central Time" is a known entity among users, and they implicitly assume that it will take care of the difference between CST and CDT (and in fact, the named timezone CST6CDT does exactly that). Hell, if Chicago one day decided to be like a few of the "weird" US cities and not follow the standard DST schedule anymore, then "America/Chicago" would suddenly not represent most of the users in what's colloquially known as "Central Time". Better to use a name like "CST6CDT" that's independent of a particular city, and thus independent of the political whims of a local government.
- justincormack 11y agoNot necessarily. I am giving a talk in San Marcos, TX at 11am next week, but I have no idea what time zone it is in as I am not American.
- notfoss 11y agoYeah, this comment is so spot on, considering that North Korea just announced a new timezone for themselves.
- jchavannes 11y agoNo mention of epoch time in the article? Just store using epoch and convert to local time zone when displaying. That's how *nix does it. https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
- lambda 11y agoUnix time is awful, since converting it to UTC is a real pain, as it doesn't count leap seconds which are included in UTC (thus, some seconds in Unix time are longer than others, or all of them are longer than standard SI seconds and the exact length fluctuates based on the introduction of leap seconds, or the like).
- jchavannes 11y agoleap seconds, or the like What else other than leap seconds are you referring to? Leap seconds are a problem for all time storage since most time parsers consider second 61 invalid [1]. They also only happen about once a year. Google just pretends they don't exist [2]. Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain. [1] https://dev.mysql.com/doc/refman/5.0/en/time-zone-leap-seconds.html https://dev.mysql.com/doc/refman/5.0/en/time-zone-leap-secon... [2] http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...
- lambda 11y agoThe "or the like" was the end of the list of ways in which you could model the divergence between Unix time and the number of SI seconds between January 1st 1970 UTC and the present. One way of modelling it is as saying that seconds in Unix time all have the same length, that differs by some factor from SI seconds, though that factor changes every time a leap second is introduced. Another way is to say that seconds don't all have constant length; some seconds have a different length than the rest of the seconds (like those in the hour or day leading up to a leap second, or even just that the one second before the leap second is twice as long as a regular second). The "or the like" was just a hedge against other possible ways of describing this divergence that I hadn't described in that one quick sentence. Pretending that leap seconds don't exist is all well and good if you have a completely closed system, but as soon as you try to synchronize with or compare timestamps with UTC, you'll start running into problems.
- comrade1 11y agoI'd hate to be this guy's customer...
- gioele 11y agoIn my past studies of documents-as-they-were-in-another-point-in-time I understood that the best way to deal with time-related information is to store all the context that you have. In this case * store the appointment date and place as a string "february 23 at 6pm here"; * store the time when the date has been uttered/written in UTC or, better, TAI; * store the place where the date has been uttered/written: "Europe/Rome" or, better, GPS coordinates. These three pieces allows you to convert the target date to any timezone, even in case the definition of timezones changes. This three-pieces encoding is very helpful during legal disputes as it allows you to say "On a certain date we agreed on this date in the future. At the time the appointment was supposed to be XXX hours away. The fact that is now only YYY hours away is not our fault but the consequence of country CCC changing to a different time zone." It also works well for other imprecise utterances like "tomorrow".
- erpellan 11y agoUnqualified absolute statements (like this one!) are always wrong. It's not possible to make a generalized assertion about the correct way to deal with time. If you're building a global distributed database, you probably want all your timestamps in UTC. If you're building a calendar application, not so much. Some systems also need to record the time the observation was made, introducing a 2nd dimension of time. This becomes important very quickly when trying to design a system with an immutable (append-only) data store.
- dg81 11y agoI collect the users city on my site using gps/browser location opt in, or by autocomplete against google locations. Has anyone figured out a way for me to get the users timezone from their city?
- bshimmin 11y agoGoogle has a timezone API: https://developers.google.com/maps/documentation/timezone/intro https://developers.google.com/maps/documentation/timezone/in...
- robmcm 11y agoBe aware of VPN, traveling users, and incorrect data. This kind of information should only be used to default preferences.
- arianvanp 11y agoI just DONT want to deal with time EVER. It's such a mess. Can't we just.. i don't know. throw away the current system and actually build something that a programmer can understand? Who counts to 24 and 60 anyway?
- aruggirello 11y agoYeah, like, let's meet at 1439193801. Quite nerdy though :)
- jozydapozy 11y agoTom Scott talking about timezones and it's quirks: https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
- vacri 11y ago> Data that’s harder for humans to inspect and verify is also more prone to errors, especially small passive errors that go unnoticed. Programmers who have to debug such data are humans. Harder for them means harder to debug, means more bugs that survive longer. QED. This is apparently an argument against UTC, but I think it's an argument against local time instead - humans comparing times stored in different timezones causes a lot of errors.
- yulkes 11y agoIn Meekan we help schedule meetings based on time ranges, like "9am in the next 3 weeks". We obviously store scheduled event times in UTC. However, that "in the next 3 weeks" day range could change offset in the middle, so we have to keep which timezone we're talking in. As kristiandupont said - timezones are great for future ones. Also, when presenting times to users, knowing what timezone they're in, helps us display the dates with the correct offsets (without need to change it twice a year). Timezone codes are useful. They're better in offsets in any way since they contain more data. It's one of those headaches for developers that save headaches to the users.
- friendzis 11y agoFirst of all, time is a relative quantity, therefore we can only measure distance in time from something. Secondly, time units do not have a fixed reference clock. `Second` is clocked by the Universe, `day` is clocked by midnight and year is clocked by New Year. Generally, by `time` we mean "distance in time since last Midnight in one second resolution" and that includes single clock source. By `date` we generally mean "distance in time since last particular arbitrary event in one day resolution", which includes two clock sources (midnight and new year). This gets rather awkward, but both sources get controlled by the "particular arbitrary event", therefore we can handle that. Combining both definitions into "distance in time since arbitrary event in one second resolution" gives us `datetime`, controlled by three clock sources. Thing are bound to get awkward. Lastly, as others have already pointed out, all this makes definitions of future events in `datetime` pretty much useless, because there is no way to predict how many ticks clock sources will generate, unless you stick with one (e.g. n Universe clocked seconds from NOW (isn't TAI exactly that?)) and deal with fluctuating clock sources in the future. Neither solution solve inherent problems with multi-clocked `datetime` definition only might make some problems easier to solve by shifting clock tracking to frontend: 2051-09-12 16:23:00 +0300 does not need to keep track of clock sources while 2051-09-12 16:23:00 Europe/Vilnius does. The whole "Bonus" section is about arbitrary{ty|ness} of "last midnight" - how long ago did it actually happen for this moving target? Should I consider offset from last midnight from time I have actually seen it or when it was supposed to be seen here? Automatic time zone settings attempt to do the latter. And if you want former semantics, well just do not use automagic and add whole new clock source to this mess - "distance in time since last time I personally thought it was midnight".
- lostfocus 11y agoMaybe we can revive that Swatch internet time?
- graniter 11y agoIt depends on how the data is going to be used. If you want absolute time, save it as UTC or local with an offset. But if a user is going to think of "7pm my time" then you probably are going to need to save "7pm" and the user's timezone separately so that 7pm always shows as 7pm even after Daylight Savings changes or other timezone rule changes. Save the date and time relative to the context of a timezone (not offset). There are a lot more timezones than there are offsets, and several timezones may have the same offset at a given point in time, but that may not be true every day of the year because they have different rules. So the robust solution is to make all your datetimes "timezone" aware, not "offset" aware. And yes that means using the Olsen Data and yes that means more complications. But it's the only way to have accuracy for human-oriented datetimes.