[tz] On solving the tzdata changes problem

[Aldrin Martoq Ahumada]

Hello,

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:
https://a0.github.io/a0-tzmigration/demo/ <https://a0.github.io/a0-tzmigration/demo/>

You can even share the url, for example here is the diff between America/Santiago 2016j and America/Punta_Arenas 2017a:
https://a0.github.io/a0-tzmigration/demo/?ta=America%2FSantiago&va=2016j&tb=America%2FPunta_Arenas&vb=2017a&m=timeline <https://a0.github.io/a0-tzmigration/demo/?ta=America/Santiago&va=2016j&tb=America/Punta_Arenas&vb=2017a&m=timeline>

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:
https://a0.github.io/a0-tzmigration-ruby/data/ <https://a0.github.io/a0-tzmigration-ruby/data/>.

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:
https://github.com/a0/a0-tzmigration-ruby <https://github.com/a0/a0-tzmigration-ruby>
https://github.com/a0/a0-tzmigration-js <https://github.com/a0/a0-tzmigration-js>

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,


— 
Aldrin.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180530/f4646326/attachment.html>