
Why You Should Use Timezone Offsets Not Timezone Names - cpeterso
http://tantek.com/2015/218/b1/use-timezone-offsets
======
wizardry90210
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.

~~~
Zarel
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
CST is not the same thing as America/Chicago. If you say CST you specifically
do not mean daylight savings time, which is CDT.

~~~
kelnos
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.

~~~
justincormack
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.

~~~
kelnos
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.

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

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

------
friendzis
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".

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

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

------
jchavannes
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)

~~~
lambda
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).

~~~
jchavannes

      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...](https://dev.mysql.com/doc/refman/5.0/en/time-zone-leap-seconds.html)

[2] [http://googleblog.blogspot.com/2011/09/time-technology-
and-l...](http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-
seconds.html)

~~~
mikehotel
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."

~~~
jchavannes
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

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

------
arianvanp
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
Yeah, like, let's meet at 1439193801. Quite nerdy though :)

------
dg81
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
Google has a timezone API:
[https://developers.google.com/maps/documentation/timezone/in...](https://developers.google.com/maps/documentation/timezone/intro)

------
lostfocus
Maybe we can revive that Swatch internet time?

------
vacri
> _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.

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

