<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2019, at 5:27 PM, Paul Ganssle <<a href="mailto:paul@ganssle.io" class="">paul@ganssle.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 1/29/19 8:43 AM, Tony Finch wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:alpine.DEB.2.20.1901291339310.18720@grey.csi.cam.ac.uk" class="">
<pre class="moz-quote-pre" wrap="">There's a common error (which is embedded in the iCalendar specification,
so it's s difficult error to avoid) of recording future times as time +
timezone name, instead of time + place. Of course, the mapping from place
-> timezone name is not stable...
</pre>
</blockquote>
One thing to note is that the mapping from place to time zone is
also not necessarily unique, and the mapping from place to relevant
political/cultural entity is <i class="">also</i> not necessarily stable.<br class=""><p class="">I think there's actually no right way to do this, at least not at
the moment, because the whole thing is built on shifting sands and
we're not able to maintain a registry of all possible adjudicating
bodies for timekeeping that will ever exist.</p><p class="">One thing that<i class=""> </i>could help with this problem and that <i class="">might</i>
be scoped well for this project to do, though, would be to ship a
machine-readable data structure that indicates something about the
history of time zone boundaries. So one example of this could be
that Asia/Qyzylorda split into Asia/Qyzylorda and Asia/Qostanay
recently. What this means is that anything that started using
Asia/Qyzylorda before the split is now ambiguous and may need to
be manually reallocated to Asia/Qostanay. Having a way to
programmatically detect when these ambiguities arise might help
things.<br class="">
<br class="">
Maybe this already exists (outside of the changelogs) and I missed
it, though.<br class="">
</p>
</div>
</div></blockquote></div><br class=""><div class="">There is no unique solution to this problem because it highly depends on application rules/local laws/user preferences/whatever.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">On a personal note, I’m against the idea of hiding the issues to our users (saving local place instead of timezone is -I think- a way of hiding or automate this problem). Instead, I think we need to exposed it in “a better way”, and let some human decide what is right (because the rules/laws/whatever are really hard to automate).</div><div class=""><br class=""></div><div class="">I really like the idea of saving time + timezone (+ tzdb version somewhere!). And make *your users choose/switch* their current timezone, and if there are issues while switching, tell them what are the issues. If a new tzdb is released, tell your users what is affected. If a place has a new timezone, tell your users about this, and if they switch to another timezone, again, tell them what is affected. Maybe your user is not your “final user”, it could be your sysadmin or whatever. But somewhere in the process of updating tzdb there should be a human that press a button saying “I’m ok with this changes” or “oh no, we need to recalculate all mortgages!”.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I wrote a tool that helps calculate what is changed whenever you change from timezone A to B and/or tzdb release X to Y (<a href="https://a0.github.io/a0-tzmigration/" class="">https://a0.github.io/a0-tzmigration/</a>). It is far from perfect, but I think it may help to build systems as I described here.</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>