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:

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:

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.