[tz] changes to the TZ database over versions
Joris Van den Bogaert
jorisvdb at esus.com
Sun Jun 1 15:51:28 UTC 2014
Oops, I forgot to compile and include "backward" as well. Many thanks.
Looking at the git log, it looks like most changes are typos and
adjustments to data far away in the past, like the early 1900's or
Big Bang :) changes and sometimes the very near future, like Egypt and
I didn't find any substantial changes that were made in the near past.
We were already planning to record both UTC and local time, but we
were considering adding an extra field TZ_VERSION. With the inclusion
of the "backward" file in the compilation process, that does not seem to be
In addition to storing the local and UTC time, I believe we need to include
the timezone id
as well. If not we'd have to version the GEO lookup tables as well.
Hypothetically, let's say Catalonia becomes a separate state on 1/1/2015 and
to have a timezone UTC+01:30 instead of CET. Do you guys then decide to
new timezone Europe/Barcelona? What (should) happens when converting
the datetime 1/1/2014 with "Europe/Barcelona", a timezone that didn't exist
at that time?
Sorry for the trivial questions, I'm new to this field.
From: Paul Eggert
Sent: Sunday, June 01, 2014 2:02 AM
To: Joris Van den Bogaert ; tz at iana.org
Subject: Re: [tz] changes to the TZ database over versions
Joris Van den Bogaert wrote:
> 1) I noticed that certain timezone ids are deleted in newer versions:
> tzdata2014a contains
> America/Shiprock, newer versions don't.
No, America/Shiprock is still present in the latest tz release. It's in
the 'backward' file. If you're concerned about backward compatibility,
you should use the 'backward' file.
> 2) Do rules from the past ever change?
Yes, it happens all the time as we find out more about the past (or, in
some cases, find out that what we thought we knew was bogus). A
proposed change of that sort for Moscow in 1921 was published today, for
> would one then recommend saving the TZ database version
One might, if one knew that one was using exactly a particular TZ
database version. But that's often not the case; if someone else
installed your database, they may have applied their own updates, e.g.,
point updates for pressing changes. And depending on your
configuration, perhaps the TZ database might be updated during your
So it might be wise for you to record both UTC and local time, instead
of trying to rely on tz version.
More information about the tz