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