<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello,<div class=""><br class=""></div><div class="">I think we can semi-automate when a tzdata change occurs in software, given the following:</div><div class=""><br class=""></div><div class="">1. Your software stores all dates as unix timestamps (seconds since the epoch, “ignoring” leap seconds).</div><div class="">2. Your system (or users) choose a local representation using an oficial timezone, like ‘America/Santiago’.</div><div class="">3. Your system stores somewhere what version of tzdata is currently being used, like ‘2018e’.</div><div class=""><br class=""></div><div class="">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?"</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">A web app that demo this concept is here:</div><div class=""><a href="https://a0.github.io/a0-tzmigration/demo/" class="">https://a0.github.io/a0-tzmigration/demo/</a></div><div class=""><br class=""></div><div class="">You can even share the url, for example here is the diff between America/Santiago 2016j and America/Punta_Arenas 2017a:</div><div class=""><a href="https://a0.github.io/a0-tzmigration/demo/?ta=America/Santiago&va=2016j&tb=America/Punta_Arenas&vb=2017a&m=timeline" class="">https://a0.github.io/a0-tzmigration/demo/?ta=America%2FSantiago&va=2016j&tb=America%2FPunta_Arenas&vb=2017a&m=timeline</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">And you can do this, in your own systems, using the same data, which is here:</div><div class=""><a href="https://a0.github.io/a0-tzmigration-ruby/data/" class="">https://a0.github.io/a0-tzmigration-ruby/data/</a>.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I’m writing a ruby gem and an npm package, would love to see other language implementations:</div><div class=""><a href="https://github.com/a0/a0-tzmigration-ruby" class="">https://github.com/a0/a0-tzmigration-ruby</a></div><div class=""><a href="https://github.com/a0/a0-tzmigration-js" class="">https://github.com/a0/a0-tzmigration-js</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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,</div><div class="">
<br class=""></div><div class=""><br class=""></div><div class="">— </div><div class="">Aldrin.</div><div class=""><br class=""></div></body></html>