[tz] DST ends 2040 in Oracle database

[Aldrin Martoq Ahumada]

> On Jan 29, 2019, at 5:27 PM, Paul Ganssle <paul at ganssle.io> wrote:
> 
> 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.
> 

There is no unique solution to this problem because it highly depends on application rules/local laws/user preferences/whatever.


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).

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!”.


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 (https://a0.github.io/a0-tzmigration/ <https://a0.github.io/a0-tzmigration/>). It is far from perfect, but I think it may help to build systems as I described here.


— 
Aldrin.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190129/8460ccd6/attachment-0001.html>