Hi Bill, You are right that the problem I noticed with timelocal() around 11/6/1910 is only present on Windows. On my Linux host, timelocal() remains consistent with DateTime module around 11/6/1910.
But your prediction for Apr 2 in 1906 does not pan out on Windows. G:\>perl David.pl 1906 04 01 08 00 00 Epoch for 19060401:080000 (UTC) = -2011881600 based on Epoch(). Epoch for 19060401:080000 (UTC) = -2011881600 based on timegm(). Epoch for 19060401:080000 (NYC) = -2011863600 based on Epoch(). Epoch for 19060401:080000 (NYC) = -2011867200 based on timelocal(). G:\>perl David.pl 1906 04 02 08 00 00 Epoch for 19060402:080000 (UTC) = -2011795200 based on Epoch(). Epoch for 19060402:080000 (UTC) = -2011795200 based on timegm(). Epoch for 19060402:080000 (NYC) = -2011777200 based on Epoch(). Epoch for 19060402:080000 (NYC) = -2011780800 based on timelocal(). G:\>perl David.pl 1906 04 03 08 00 00 Epoch for 19060403:080000 (UTC) = -2011708800 based on Epoch(). Epoch for 19060403:080000 (UTC) = -2011708800 based on timegm(). Epoch for 19060403:080000 (NYC) = -2011690800 based on Epoch(). Epoch for 19060403:080000 (NYC) = -2011694400 based on timelocal(). timelocal() assigns UNIX times -2011867200, -2011780800 and -2011694400 respectively, exactly 86400 apart and thus shows no sign of DST switch on either 19060402 or 19060403. ---------------------------------------------------------------------------- ----------------------- As Dave mentioned, that the concept of local time in USA before 11/18/1883 (when railroad finally brought in the standard time) was all but meaningless, so I would just retrict timelocal() and localtime() usage after 11/19/1883 on Linux (and after 11/7/1910 on Windows). But a more intriguing problem I noticed is that, on both Windows and Linux, timegm() starts to fail at around Feb, year 0000 AD, while gmtime() and DateTime module continue to hold up. For example: timegm(gmtime(-62163198000)) returns -62163111600. The fault here seems to be with timegm(), not gmtime(). Lu -----Original Message----- From: Bill Ricker [mailto:bill.n1...@gmail.com] Sent: Thursday, March 16, 2017 7:47 AM To: Dave Rolsky Cc: Lu Feng; datetime@perl.org Subject: Re: FW: timelocal() discrepancy vs DateTime->epoch > I'm pretty sure timelocal() is wrong here, though I'm not sure why. > There was no DST transition in that zone in 1910. In fact, there > wasn't really a time zone until 1918. The pre-1918 zone file in the > Olson database is just using local solar time, but it's not very > meaningful. If you really care about local times in the early 1900s > you probably need to calculate the solar noon for the given lat/long. This is likely to be a Y2K/19100 window wrap issue. The little dst.pl script that I use to check Olson DB -- used in 2007 to diagnose which servers needed Olson/TZ DB update -- also reports DST transitions for 2010 when asked for 1910. [ i think i grabbed it from blogs.perl.org and enhanced it ? no authorship is noted ] $ dst.pl -y 1910 Sun Mar 14 01:59:59 EST 2010 --> Sun Mar 14 03:00:00 EDT 2010 Sun Nov 07 01:59:59 EDT 2010 --> Sun Nov 07 01:00:00 EST 2010 (That script uses localtime(), Time::Local and POSIX qw(strftime), but not DateTime.) Supporting evidence -- Early November DST transition was novel in 2007. (Giving the little trick-or-treaters the extra hour of daylight at Hallowe'en was obviously desirable for decades, but it took until 2007 to get it done.) I predict Lu's script will report DST transitions morning of Apr 2 and Oct 29 in 1906, since those were the dates in 2006. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux
