[tz] On solving the tzdata changes problem
Aldrin Martoq Ahumada
aldrin.martoq at gmail.com
Thu May 31 03:29:15 UTC 2018
I think we can semi-automate when a tzdata change occurs in software, given the following:
1. Your software stores all dates as unix timestamps (seconds since the epoch, “ignoring” leap seconds).
2. Your system (or users) choose a local representation using an oficial timezone, like ‘America/Santiago’.
3. Your system stores somewhere what version of tzdata is currently being used, like ‘2018e’.
So, when a new version of tzdata is released (say ‘2018f’), the sysadmin updates their tzdata packages, and then runs a tool that checks for every timezone used (‘America/Santiago’ for ex) if there are changes that could affect users between 2018e and 2018f. The typical example: my dentist appointment is not correct anymore. So, your system may ask the user: “There have been changes in the timezone where you live, would you like to review this 3 appointments and check if they are still correct?"
The problem is that there is no historical data of tzdata: when a sysadmin updates the system, it gets a new version 2018f, but there is no automatic way of knowing the differences. I didn’t find one, so I wrote it.
A web app that demo this concept is here:
You can even share the url, for example here is the diff between America/Santiago 2016j and America/Punta_Arenas 2017a:
This can automate many issues we all have when updating tzdata. For the link above, a whole region of my country switched so the new America/Punta_Arenas timezone was created. You can easily spot errors, too: the America/Punta_Arenas should be equal to America/Santiago up to 2017, but there are differences in the years 1890, 1946.
And you can do this, in your own systems, using the same data, which is here:
It’s not perfect. It probably has errors. I generated it from the ruby tzinfo-data gem, which has info only from 2013c onwards, and transitions up to ≈ 2068 (50 years from now). Use with caution, happy to accept corrections.
I’m writing a ruby gem and an npm package, would love to see other language implementations:
API is not really stable, will check and release documentation next week, but the core idea is there: grab the JSON files from our github page and get the changes that MAY have to be applied.
I’m writing a medium blog post to cover all of this. Hope that this help all of you, and happy to listen any suggestions or corrections. Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz