Why You Should Use Timezone Offsets Not Timezone Names(tantek.com)
tantek.com
Why You Should Use Timezone Offsets Not Timezone Names
http://tantek.com/2015/218/b1/use-timezone-offsets
50 comments
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..
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
[0] https://en.wikipedia.org/wiki/Tz_database
See: Example zone and rule lines
I 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.
Storing the offset won't work for future dates due to daylight savings changes.
True, 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.
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.
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.
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.
The ones that have a tiny map that you have to click on are also pretty bad.
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!)
(And I may be further proving your point if Denver isn't the landmark city, I'm just guessing!)
The reason for Country/City is because the timezone name is a global reference. It may be written in english, but everybody uses. Things like "pacific", "central" and "standard" mean very different things in other places.
Indeed, for many years the Eastern time zone in Australia was shortened to EST (Eastern Standard Time); just like the US Eastern time. With the wider advent of the Internet Australia renamed EST to AEST (Australian Eastern Standard Time).
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".
https://en.wikipedia.org/wiki/Central_Time_Zone
The one in the Americas is the only one called "Central Time". It may not be the most politically correct name, but it happens to be the only name for it I know of, and it's the only timezone with that exact name worldwide.
The one in the Americas is the only one called "Central Time". It may not be the most politically correct name, but it happens to be the only name for it I know of, and it's the only timezone with that exact name worldwide.
https://www.iana.org/time-zones
"America/Chicago" is a standard timezone name.
"America/Chicago" is a standard timezone name.
Right, but very few people living in the continental US[0], when presented with a timezone dropdown, are going to expect to see anything but Eastern, Central, Mountain, or Pacific. If they do see a list that has city names, they'll be confused that their city isn't mentioned, or that they're expected to pick a city that's in their timezone but possibly geographically distant.
Personally, I (living in SF), use the "PST8PDT" named timezone; it just makes more sense to me than "America/Los Angeles", which is 400+ miles away from me (even though historically we've always had the same time as LA... as far as I know).
[0] Yes, there are a few places in the continental US that don't follow the "normal" 4 timezones and their DST schedules, so there are exceptions; specifically calling out those cities/locales is necessary, at least in those cases.
Personally, I (living in SF), use the "PST8PDT" named timezone; it just makes more sense to me than "America/Los Angeles", which is 400+ miles away from me (even though historically we've always had the same time as LA... as far as I know).
[0] Yes, there are a few places in the continental US that don't follow the "normal" 4 timezones and their DST schedules, so there are exceptions; specifically calling out those cities/locales is necessary, at least in those cases.
I just googled "Omaha, NE timezone", and "America/Chicago" was not anywhere in the results.
http://google.com/search?q=Omaha,+NE+timezone
It may be a standard timezone name, but it's not a very user-friendly one.
http://google.com/search?q=Omaha,+NE+timezone
It may be a standard timezone name, but it's not a very user-friendly one.
CST is not the same thing as America/Chicago. If you say CST you specifically do not mean daylight savings time, which is CDT.
Sure, 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.
A fair number of timezones don't have a name for the full timezone that implies those specific daylight savings rules. Maybe it'd work for there and they should call CST6CDT, "Central Time".
Not 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.
I'm not talking about people in your situation; I guess that wasn't clear. I'm talking about someone setting the time zone on their personal hardware. They know where they live and what their time zone is.
Besides, for your case there are easier methods, like Googling "current time in San Marcos, TX" (which Google will actually tell you the time and time zone without you needing to click on a results page; if you feel the need to, the first result has all the info you need as well). Hell, the "world clock" app on my phone tells me what I need to know when I enter in that city.
Besides, for your case there are easier methods, like Googling "current time in San Marcos, TX" (which Google will actually tell you the time and time zone without you needing to click on a results page; if you feel the need to, the first result has all the info you need as well). Hell, the "world clock" app on my phone tells me what I need to know when I enter in that city.
No, if you say CST you specifically mean China Standard Time. Most people in the world would agree.
And more commonly, EST doesn't mean just Eastern.
My bad, I'll update my comment.
Yeah, this comment is so spot on, considering that North Korea just announced a new timezone for themselves.
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".
* 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".
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.
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.
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.
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.
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".
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".
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.
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.
Tom Scott talking about timezones and it's quirks: https://www.youtube.com/watch?v=-5wpm-gesOY
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
https://en.wikipedia.org/wiki/Unix_time
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).
leap seconds, or the like
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...
The "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.
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.
How is Google's leap smear idea pretending like leap seconds don't exist? As per your link, "The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens."
[deleted]
From the article:
> Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. [..] Rather than doing this, we applied a patch to our internal NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight
> Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. [..] Rather than doing this, we applied a patch to our internal NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight
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.
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.
That being said, the gist of the post (time normalization) is obviously good. Stored time should always be UTC and converted for display later.
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?
Yeah, like, let's meet at 1439193801. Quite nerdy though :)
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?
Has anyone figured out a way for me to get the users timezone from their city?
Google has a timezone API: https://developers.google.com/maps/documentation/timezone/in...
Be aware of VPN, traveling users, and incorrect data. This kind of information should only be used to default preferences.
Maybe we can revive that Swatch internet time?
> 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.
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.
I'd hate to be this guy's customer...
Storing UTC offsets means that any future political changes will result in the wrong local times for users.