[tz] DST ends 2040 in Oracle database

[Paul Ganssle]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190129/9ce5935d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20190129/9ce5935d/signature.asc>