Why You Should Use Timezone Offsets Not Timezone Names

http://tantek.com/2015/218/b1/use-timezone-offsets

by cpeterso • 11 years ago

26 49 11 years ago

thriqon• 11 years ago

While 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• 11 years ago

Came 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• 11 years ago

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

lambda3• 11 years ago

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

tadfisher• 11 years ago

TZDATA ships with historical timezone information, so using the timezone name should also work for past events, no?

kristiandupont• 11 years ago

Which 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• 11 years ago

If you're using the Olsen Database[0], aren't past (and future) changes all handled properly?

[0] https://en.wikipedia.org/wiki/Tz_database

See: Example zone and rule lines

Zarel4• 11 years ago

I 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• 11 years ago

CST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.

gohrt• 11 years ago

https://www.iana.org/time-zones

"America/Chicago" is a standard timezone name.

function_seven• 11 years ago

I think one of the reasons "Country/City" is used is due to variances within a timezone. Take Mountain Time, for example. "America/Denver" is different from "America/Phoenix" due to Arizona not observing daylight savings time. So in the middle of summer, America/Denver will translate to MDT while America/Phoenix will be MST.

(And I may be further proving your point if Denver isn't the landmark city, I'm just guessing!)

nvivo4• 11 years ago

Central to where? The other 96% of the world that are not in the US don't agree with your very specific notion of "central".

notfoss• 11 years ago

Yeah, this comment is so spot on, considering that North Korea just announced a new timezone for themselves.

jchavannes3• 11 years ago

No 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

lambda3• 11 years ago

Unix 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).

jchavannes3• 11 years ago

  leap 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-secon...

[2] http://googleblog.blogspot.com/2011/09/time-technology-and-l...

comrade1• 11 years ago

I'd hate to be this guy's customer...

gioele• 11 years ago

In 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• 11 years ago

Unqualified 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• 11 years ago

I 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• 11 years ago

Google has a timezone API: https://developers.google.com/maps/documentation/timezone/in...

robmcm• 11 years ago

Be aware of VPN, traveling users, and incorrect data. This kind of information should only be used to default preferences.

arianvanp• 11 years ago

I 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• 11 years ago

Yeah, like, let's meet at 1439193801. Quite nerdy though :)

jozydapozy• 11 years ago

Tom Scott talking about timezones and it's quirks: https://www.youtube.com/watch?v=-5wpm-gesOY

vacri• 11 years 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• 11 years ago

In 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• 11 years ago

First 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• 11 years ago

Maybe we can revive that Swatch internet time?

graniter• 11 years ago

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

Why You Should Use Timezone Offsets Not Timezone Names

Related Stories