[tz] changes to the TZ database over versions

[Joris Van den Bogaert]

Hi Paul,

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 
Turkey.
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 
necessary.

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 
decides
to have a timezone UTC+01:30 instead of CET.  Do you guys then decide to 
create a
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.

Cheers,
Joris

-----Original Message----- 
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
example; see:

https://github.com/eggert/tz/commit/8d558674ce15736f4db98332e9d1e86b1555c340

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

So it might be wise for you to record both UTC and local time, instead
of trying to rely on tz version.