On Mon, Jul 10, 2017 at 2:19 PM, Dave Rolsky <auta...@urth.org> wrote:
> While you could in theory write code that would be correct for all past
> datetimes, the future doesn't work the same way. As Eric noted, time zones
> are political. I have seen DST transitions altered with mere days (or
> less!) notice given. This means that anything you determine about the
> future could be wrong.
>
Yes, this. Seen same. Nice polities give much more notice but certain
countries have had decrees canceling a short notice change after IT
scrambled and couldn't finish, so IT had to unscrambe even faster. Or
canceling a suspension at last minute.
Hypothetically, that 'half' of Indiana could on short notice decide to do
DST after all next year. One might hope it would be planned in advance ...
but notice of Haiti resuming DST this year was pretty short.
Closer to home and concrete, Maine is actively lobbying to convince Mass &
NH to stay on EDT all winter (effectively switching to Atlantic Standard
time in winter and EDT in the summer), so no one knows if the EDT-EST
transition will happen this fall in New England this year or next year?
USA DST was a fixed algorithm for decades and we got used to it and tech
got lazy.
(Many devices produced pre 2006 had no way to update their built in DST
algorithm! I had to set timezone manually 4x per year on my old phone and
GPS. )
So we had quite the snipe hunt to find all separate time zone file
copies in the distributed corp datacenters when the algorithm would change
in 2007 (from April/October to March/November) and check which applications
would (a) care about DST at all (b) use OS, Java, Perl module, or other
TZinfo/zonefile source, and remediate appropriately the few that _would_
hiccup.
> 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 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 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!)
