
<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <div class="moz-cite-prefix">On 1/29/19 8:43 AM, Tony Finch wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:alpine.DEB.2.20.1901291339310.18720@grey.csi.cam.ac.uk">

      <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>also</i> not necessarily stable.<br>

    <p>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>One thing that<i> </i>could help with this problem and that <i>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>

      <br>

      Maybe this already exists (outside of the changelogs) and I missed

      it, though.<br>

    </p>

  </body>

</html>