Package: tzdata
Version: 2016a-1
Severity: wishlist
Hi,
When running "dpkg-reconfigure tzdata" to reconfigure my machine's time
zone, one of the choices presented on the "US" menu is
"Pacific-New". Apparently this is a reference to a proposed time zone
that never became law in the U.S.:
http://catless.ncl.ac.uk/Risks/13.87.html#subj1
US presidential election year politics help cause time zone bugs
Paul Eggert <egg...@twinsun.com>
Mon, 26 Oct 92 14:47:57 PST
Several people on the west coast of the US reported that their Unix
systems failed to switch from daylight savings time to standard time
yesterday, 25 October 1992. The reason? When they originally
configured their systems, they were asked to choose one of the
following time zone rules:
US/Alaska US/Central US/Hawaii US/Pacific
US/Aleutian US/East-Indiana US/Michigan US/Pacific-New
US/Arizona US/Eastern US/Mountain US/Samoa
...
Some people chose `US/Pacific-New' instead of `US/Pacific'. After
all, who wants the old version when you can have the new version?
Unfortunately, `US/Pacific-New' stands for ``Pacific Presidential
Election Time'', which was passed by the House in April 1989 but
never signed into law. In presidential election years, this rule
would have delayed the PDT-to-PST switchover until after the
election, to lessen the effect of broadcast news election
projections on last-minute west-coast voters. Thus, US/Pacific-New
and US/Pacific have always been identical -- until yesterday.
This problem comes from combining Arthur David Olson's deservedly
popular time zone software (which you can FTP from elsie.nci.nih.gov
in pub/tz92b.tar.Z) with some overly terse vendor-supplied
installation procedures. No doubt Olson did not use a more
informative name like `US/Pacific-Presidential-Election' because of
the 14-character file name length limit in many Unix file systems.
In view of yesterday's experience, though, it seems unwise to make
the hypothetical choice available under any name, since it gives
free rein to Murphy's Law.
Interestingly, US/Pacific and US/Pacific-New appear to now be aliases
for the same underlying time zone:
edmonds@chase{0}:~$ dpkg -S US/Pacific
tzdata: /usr/share/zoneinfo/US/Pacific-New
tzdata: /usr/share/zoneinfo/right/US/Pacific-New
tzdata: /usr/share/zoneinfo/posix/US/Pacific-New
tzdata: /usr/share/zoneinfo/posix/US/Pacific
tzdata: /usr/share/zoneinfo/right/US/Pacific
tzdata: /usr/share/zoneinfo/US/Pacific
edmonds@chase{0}:~$ ls -l /usr/share/zoneinfo/{right/,posix/,}US/Pacific*
lrwxrwxrwx 1 root root 18 Jan 29 15:28 /usr/share/zoneinfo/US/Pacific ->
../SystemV/PST8PDT
lrwxrwxrwx 1 root root 18 Jan 29 15:28 /usr/share/zoneinfo/US/Pacific-New
-> ../SystemV/PST8PDT
lrwxrwxrwx 1 root root 21 Jan 29 15:28 /usr/share/zoneinfo/posix/US/Pacific
-> ../../SystemV/PST8PDT
lrwxrwxrwx 1 root root 21 Jan 29 15:28
/usr/share/zoneinfo/posix/US/Pacific-New -> ../../SystemV/PST8PDT
lrwxrwxrwx 1 root root 18 Jan 29 15:28 /usr/share/zoneinfo/right/US/Pacific
-> ../SystemV/PST8PDT
lrwxrwxrwx 1 root root 18 Jan 29 15:28
/usr/share/zoneinfo/right/US/Pacific-New -> ../SystemV/PST8PDT
So the behavior described in 1992 for the "US/Pacific-New" time zone
isn't even replicable any more:
edmonds@chase{0}:~$ zdump -v /usr/share/zoneinfo/posix/US/Pacific-New |
grep 1992
/usr/share/zoneinfo/posix/US/Pacific-New Sun Apr 5 09:59:59 1992 UT = Sun
Apr 5 01:59:59 1992 PST isdst=0 gmtoff=-28800
/usr/share/zoneinfo/posix/US/Pacific-New Sun Apr 5 10:00:00 1992 UT = Sun
Apr 5 03:00:00 1992 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/posix/US/Pacific-New Sun Oct 25 08:59:59 1992 UT = Sun
Oct 25 01:59:59 1992 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/posix/US/Pacific-New Sun Oct 25 09:00:00 1992 UT = Sun
Oct 25 01:00:00 1992 PST isdst=0 gmtoff=-28800
Probably that's a hack to fix the time on systems where the sysadmin
inadvertently chose the wrong timezone. Maybe US/Pacific-New should be
removed, or at least not displayed in the "dpkg-reconfigure tzdata"
menu?
--
Robert Edmonds
edmo...@debian.org
