On 10.07.2017 23:17, Bill Ricker wrote: > On Mon, Jul 10, 2017 at 2:19 PM, Dave Rolsky <auta...@urth.org > <mailto:auta...@urth.org>> wrote: > >[...] > If you're trying to avoid these, the best advice I could give would > be to avoid the 12am-4am window, which AFAIK is when most (all?) > transitions have occurred historically. > > > Or postpone conversion from text time to DateTime or time_t ; store as > Zulu what is absolute and store as Local to a Zipcode what is > local/human, and do just-in-time conversion it to time_t or DateTime as > needed for computation, according to the rules for that date when > inspected. > > > In 2007 to prepare for the algorithm change -- the time-change date > change -- i used a Perl script to check what the OS TZ said next > transition for USA Eastern time-zone was for something like 100 servers > to see which had been updated and which hadn't. (Had to delegate > actually running it to someone who had ssh or sudo everywhere. I > packaged a script and did data reduction and mapped hosts to > applications. Also did a find to find DateTime.pm and Java JRE/JDK > equivalent.) > See contemporaneous notes for more information. > http://use.perl.org/use.perl.org/_n1vux/journal/32234.html > and > http://www.nntp.perl.org/group/perl.datetime/2017/03/msg8132.html > The script dst.pl <http://dst.pl> is still available as > > https://community.hpe.com/hpeb/attachments/hpeb/itrc-153/7220/1/285887.pl > from > > https://community.hpe.com/t5/Patches/Daylight-Savings-Time-for-HP-UX-10-20/m-p/3923972 > > > Note that this perl script uses libc() -> OS TZinfo (and requires no > CPAN iirc), not DateTime::TimeZone's, but the same logic could scan > forward for the flip with DateTime. I didn't do that because i could > just check the DateTime version iirc. > > But as described by Dave and elaborated above, trying to predict the > future and storing the predicted conversion allows governments to give > you bugs (that your users will blame you for, alas, unfair though that > seems) that upgrading your DateTime won't fix, since you already did the > conversion. Whereas if you store the user input and convert it at-need, > you can update the TZ info by updating OS and/or modules when > politicians make a change and calculations will be right on the day. > > For those wanting much too much more info on TimeZones and the trouble > with keeping them current: > * Prior releases of DateTime::TimeZone had a maintainers' README that > referenced the master node of TZ nerdery > http://www.twinsun.com/tz/tz-link.htm > but that file has been supplanted by a README.md build from the > pod2man , so i include that link, along with Wikipedia for an easier enty - > * https://en.wikipedia.org/wiki/Tz_database > (which redirects from https://en.wikipedia.org/wiki/Olson_database ) > * and the TZ data maintainer mailinglists > tz news:comp.time.tz <http://comp.time.tz> > https://mm.icann.org/listinfo/tz http://mm.icann.org/pipermail/tz/ > & tz-announce http://mm.icann.org/pipermail/tz-announce/ > ( Yes, the TZ data is now an official function of the Internet Assigned > Numbers Authority (IANA) and is supperted from IETF and ICANN. ) > (I am pleasantly surprised there hasn't been a TZ data release since > March ... which was the just-in-time update for Haiti resuming DST this > year, the sort of predict-the-future problem mentioned. If one has > worldwide users using their own TZs, one needs regular updates!)
Thank you very much for your elaborated answer and all the links! I will try to read that stuff within the next days. The nature of the application requires the most recent time zone information to be used in every case, so I'd like to avoid "calculating the future" (as a last resort, I could "calculate the future" every time the timezone database is updated). But I still think that DateTime already knows whether a date-time is (or will be) ambiguous (according to the timezone data known so far, which would perfectly fit my requirements - see my previous post), so we "only" would need a new function to query that information. I could be wrong, though. If DateTime can't provide an appropriate function, I eventually will try to extract the daylight switching information from the timezone database and try to make an own algorithm to solve the problem. The script you mentioned is probably a good starting point (did not look into it yet). Regards, Binarus
