
Timezone updates need to be fixed - laut
http://www.creativedeletion.com/2015/12/03/timezone-updates-need-fixing.html
======
Khao
Where I work we deal a lot with events (yoga gyms, community sports centers,
etc.) and the old code was saving EVERYTHING in UTC. Every 6 months we'd have
some bug report coming in saying that some event was now one hour later or
earlier on the website, or in some report, or in an admin edit screen.

I got fed up with this and migrated all the data so it's saved in local time
with the timezone information in a separate column. If an admin creates an
event for 4pm, we save 4pm with the event location's timezone. Since an event
only takes place at one specific location, it makes no sense to have the data
in UTC in the database. We can convert to UTC if we want but it's not really
useful. The thinking is that if a client is shopping for a class in a
different timezone, why would we convert the class's time to the client's
timezone? It makes no sense. It's always in local time. This has helped so
much.

~~~
vemv
Seems a misguided practice to me.

* Store datetime values in UTC. Else you get inconsistent values, which has unpredictable consequences.

* Detect user's expected timezone using one of : a) user preference setting, b) the region the app is supposed to be running for, c) IP geolocation. Choice depends on the app requirements. Don't default to any timezone unless considered 100% safe.

* Present DB values in the UI using said detected timezone.

* UI-wise, slways display timezone information for datetime values. At the very least in a tooltip.

~~~
laut
It is not misguided, it is a good practice. Read more about why here:
[http://www.creativedeletion.com/2015/03/19/persisting_future...](http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html)

~~~
feld
I disagree. Storing as UTC is the only sane way. It will never get corrupted.
Calculating the timezone difference for the user is not that hard and won't
result in a database full of mistakes you have to scramble to fix.

~~~
Avernar
Not for events like shows, movies, work hours, etc. An event starts and stops
at a specific local time. If the DST rules change then the UTC version will be
wrong but the one stored in local time + TZ will be correct.

Intervals should be stored in UTC. If you're supposed to drop the control rods
in a reactor in 24 hours you store the time it's supposed to happen in UTC.
DST transitions and rule changes would mess this up if stored in local time.

Timestamps for logs and files should also always be UTC.

~~~
feld
UTC is an anchor. It does not change, it is never wrong. Your application or
environment may live under different rules because of location but that
problem can be solved by the timezone-aware application.

If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00
UTC. If my timezone changes due to a new law UTC is not wrong; the event is
still going to happen at 13:00 UTC! If the event was previously stored as a
local time and not UTC the _EVENT_ is wrong! You solve this by handling the TZ
conversion elsewhere and making sure it always has the latest rules.

Always store in UTC. Your argument makes no sense.

~~~
laut
If the user expects 8:00 local time then it should stay 8:00 local time. That
is at least how people would want their applications to work 99% of the time.
If someone enters 8:00 and then the software suddenly changes it to something
else, that is confusing.

If you actually look at what happens when timezone laws change, people
continue to anchor to their local times.

~~~
feld
Congratulations you literally just rescheduled the event. This is not a
timezone issue. The date should still be stored as UTC.

~~~
Avernar
Wrong. Let's say an event is scheduled for 6pm daily in Toronto (EST -0500).
You store it as 11pm UTC. Now eventually we switch to EDT -0400 due to DST.
Now your system will say the event is at 7pm local time.

YOU just rescheduled the event.

Works the same with dates and not just times. If you store each of those
events individually and the politicians move the DST switch date (or an error
was corrected in the TZ database) then some of your event times will now be an
hour off.

~~~
feld
The event was literally moved to a different time UTC. I'm glad we agreed that
it was rescheduled.

UTC is still the correct way to store it if you want it to be timezone-aware.

If every event a specific application needs to be at local time regardless of
what the timezone is, stop storing any reference to a timezone.

~~~
Avernar
We don't agree. It was not rescheduled in reality. Your system would have said
it was rescheduled to 7pm Toronto time while in reality the event would still
be 6pm Tronto time. The people using your site/app/whatever would be an hour
late.

UTC is the correct was to store timestamps (things that happened) and
intervals (things that need to happen x seconds/minutes/hours from now).

For future events at a specific geographical location you need to store it as
local time + timezone. Many databases have a time+timezone type.

~~~
halostatue
I would go as far to say that the timezone stored should be a _named,
geographically-based_ timezone (e.g., America/New York or Canada/Eastern) as
opposed to a timezone _offset_. (If you store the timezone as EDT or EST, you
have still encoded -0400 or -0500.)

~~~
Avernar
The postgres documentations says exactly that. Other databases might do
something else so it's best to read the documentation.

------
sbierwagen

      But the data itself is not new software. It is just data. 
      Functionality should not change because of new data.
    

Well, _ideally_ , yes. But software breaks all the time when you give it data
the programmer didn't expect, which happens especially often with time.

DST, for example. What if a state _stops_ observing DST? Arizona observed DST
in 1967, but hasn't since then. A couple other states are considering
abolishing it, too. You can easily imagine software doing something dumb when
it can't find its DST entry in tzdata.

~~~
laut
I don't think it is a good idea to shield bad software at the expensive of
having incorrect out-of-date data. Developers should be aware that tzdata
changes all the time, and create software that can deal with it.

------
petke
I got programs connecting to servers in different countries. It was such a
pain to keep the time in sync with all the different time zones and daylight
savings. So i ended up using utc everywhere. i even set the clock on the wall
and my wrist watch to utc. That way I'm also in sync with my programs. People
who visit tell me my clocks are wrong. But i know its the the rest of the
world that is wrong.

~~~
sbierwagen
Use unix time and NTP.

~~~
petke
Yes. Unix time is utc based. I used manual syncing to ntp server once in a
while. Automatic syncing scares me a bit. What happens when it adjust
backwards in time. Programs that are running and use elapsed time logic might
get very confused. Elapsed time since an event happened might become negative.

~~~
HeXetic
> What happens when it adjust backwards in time.

NTP deliberately makes only very tiny changes gradually when adjusting clock
time backwards. Automatic updates also normally abort if the time difference
would be more than 1000s (~16m). This is all fairly well-documented.

[https://www.eecis.udel.edu/~mills/ntp/html/index.html](https://www.eecis.udel.edu/~mills/ntp/html/index.html)

~~~
petke
Interesting. Still any backward adjustment however small seems potentially
dangerous. I googled a bit and it seems many ntp services can slow down the
time until its in sync instead of adjusting it backwards. That seems safer.

~~~
gwright
Generally it isn't a backward adjustment but simply a slowing down of the
clock until the 'real time' catches up. On the other side, you speed up a
clock to catch up to the real time rather than catching up all at once.

------
phicoh
Looking at this from a 'Unix in Europe' perspective, the timezone data has
rules. So as long as the rules don't change you don't need updates. And due to
the need to coordinate with many countries, timezone rules in the EU
essentially don't change.

It seems that in some countries, time zones just change randomly. Maybe people
should just stop doing that. Countries only move a couple of centuries a year.
And there is no reason to mess with DST other than to get rid of it all
together.

~~~
maw
_Maybe people should just stop doing that._

I don't disagree, but how do we get there from here? Our "betters" have even
had the gall to make this type of change in the recent past, and even to claim
"energy efficiency" as a motivation. This is is--how do I put this?--a wronger
than wrong version of not even wrong.

~~~
phicoh
One option is to get one of those big name companies to write a report on how
much that change cost to the economy due equipment that had to be written off,
downtime, etc.

Doesn't have to accurate, just impressive. And then maybe next time, circulate
the report just before the decision has to be taken.

------
gregmac
One of the biggest problems with tzdata is only mentioned in passing in the
article:

> If you make a system that uses timezone data, think ahead. The timezone data
> is updated as often as 10 times a year or more. In case you have an embedded
> system that is not connected to the internet all the time, how can that
> processes be put in place to make sure it is updated?

A decade or so ago, nothing updated, and when DST changed, you had to reset
every clock in the house. There was maybe a day or two of confusion where you
couldn't remember if you changed a clock or not, but easily dealt with.

Now, in my house anyway, _almost_ everything automatically switches (with the
notable exception of my stove and microwave clocks, but heck, those still
don't even have battery backup for when the power flickers). This is probably
even more annoying, because now it's not a matter of remembering if _I_
switched it (in the last day or so) or not, it's remembering if the _device
itself switches automatically_ or not. I can't remember stuff like that, so
basically for a day or two after DST I don't trust any clocks at all.

Worse is when the devices still have the old (pre-2007) DST rules built-in.
We're lucky in NA that the rules don't change _that_ much, but when they do,
they do break all these old devices. The most annoying item I had (notice past
tense) was a beside clock that auto-set itself I believe based on the WWV [1]
signal, and had a setting for time-zone and would of course do DST shifts
automatically. Pretty neat, when I first got it, but after 2007, I had to
manually change the timezone on this "auto-setting clock" 4 times a year.

[1]
[https://en.wikipedia.org/wiki/WWV_(radio_station)](https://en.wikipedia.org/wiki/WWV_\(radio_station\))

~~~
teraflop
> Pretty neat, when I first got it, but after 2007, I had to manually change
> the timezone on this "auto-setting clock" 4 times a year.

That's odd, because the WWV signal contains extra flag bits that
authoritatively tell you when DST is starting and ending. I guess the
manufacturers decided to ignore that data and reimplement the time change
themselves.

[https://en.wikipedia.org/wiki/WWV_(radio_station)#Daylight_s...](https://en.wikipedia.org/wiki/WWV_\(radio_station\)#Daylight_saving_time_and_leap_seconds)

~~~
gregmac
Wow, that actually makes me very frustrated, because it means not only did
they ignore that flag (not read the documentation?), they actually did more
work to implement a tzdata database and check against the current date to
change it.

Of course, IIRC it also only had 4 timezone settings, so I guess if you lived
in Hawaii, Alaska, the Atlantic time zone, or Newfoundland, you were out of
luck. And if you lived in Arizona or Saskatchewan or any other place that
didn't observe DST, you were also out of luck. (Well, you could at least
manually adjust the time, which I think turned off the auto-DST stuff).

------
Grue3
My HTC One still uses years old timezone information for its clock widget. I
fixed the main clock by setting timezone to a different timezone that I'm
actually in, but the clock widget is still off by one hour. It's extremely
infuriating. Apparently you can't update timezone information in Android
unless you have root, which is completely idiotic.

------
laut
2016a has been released: [https://www.iana.org/time-
zones](https://www.iana.org/time-zones)

If you use the Elixir library mentioned in the article, it will already have
been updated. If you use Mac OS X Yosemite it will probably never be updated.

------
SFjulie1
Timezone problems (cf The Problem with Time & Timezones - Computerphile on
youtube or postgres doc on why not to use TZ) are not solvable.

TZ are politics and politic is very bad at making stuff engineerable. Politics
are inconsistent, unstable and lack of rigor in propagating the information to
the coders.

The TZ definitions are handled by clerks that writes an XML files manually
that are embedded in your libs and that no one cares to update.

TZ are not versioned. So if you want to know what was the local time 12years
ago in any place of the world : good luck.

But international exchange are bound to delays workhours and SLA requiring
delays to be measurable ... With arbitrary changes (EST shit).

Timezones are broken by design and all our applications too.

The only way to solve the problem is to forbid politics to come anywhere near
science, history and standardization of measurement. Corporation don't do any
better. I abide by International System (metric) and the idea that there
should be a monotonic non disrupted absolute time whose origin IS NOT the
birth of Christ but since when we are able to have continuous "rigorous"
measurement of time.

Which is exactly the opposite of what people calls for.

The begining of the year should be the aphelia (3~4 jan) and not some
religious bat shit conventions. Noon should be when the sun is at its top. And
13 month of 28 days (+intercalar days) would make our lives easier.

Time as a political and religious construct is shit.

------
kijeda
The IETF has been working on distribution issues and, amongst other documents
from the tzdist working group, produced this:
[https://datatracker.ietf.org/doc/draft-ietf-tzdist-
service](https://datatracker.ietf.org/doc/draft-ietf-tzdist-service)

------
TheBranca18
As someone who just spent some time figuring out why Australians were getting
errors on the site I work for, I fully support standardizing automatic
updates. Since the site is running a two year old version of PHP, it looks
like I either have to update the PHP version to the latest (just to be safe)
or add the timezonedb PECL package. This seems to be a ton of work just to get
something that should be updated automatically.

------
vemv
Are up-to-date Rails applications exposed to this issue?

Not 100% sure, but from what I know, Rails gets timezone handling right.
Specifically, it leverages the
[https://github.com/tzinfo/tzinfo](https://github.com/tzinfo/tzinfo) gem. So,
correct me if I wrong, by performing `bundle update` you're all good?

~~~
laut
AFAIK you can use the tzinfo-data gem. Someone needs to manually update it
though. So far it looks like it is still on the previous 2015g and not on
2016a that just got released: [https://github.com/tzinfo/tzinfo-
data](https://github.com/tzinfo/tzinfo-data)

------
ape4
How about a way to encode future timezone changes? If a country votes for a
timezone change it doesn't become law tomorrow. Usually they schedule it for a
date in a few months. If a week after the vote tzdata knew this then there
would be no rush.

~~~
smackfu
Here's an example from Argentina in 2007:
[http://blogs.technet.com/b/dst2007/archive/2007/12/29/argent...](http://blogs.technet.com/b/dst2007/archive/2007/12/29/argentina-122907.aspx)

Less than a week's notice of the change, and it was between Christmas and New
Year. Ouch.

~~~
ape4
They deserved all the wrong times they probably got.

------
Happpy
All use utc and stop the daylight saving and timezone...

Use gps coord. And utc to know if you have a lunch or breakfast, dinner
meeting

Time zones have no precision so why use them?

~~~
BurningFrog
I agree, but to do that you need root to the World.

As long as we're regular users, we need to work around these realities.

