On 1/29/19 8:43 AM, Tony Finch wrote:
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... 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 /also/ not necessarily stable.
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. One thing that//could help with this problem and that /might/ 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. Maybe this already exists (outside of the changelogs) and I missed it, though.