Skip Menu |

This queue is for tickets about the Time-y2038 CPAN distribution.

Report information
The Basics
Id: 40765
Status: resolved
Priority: 0/
Queue: Time-y2038

People
Owner: Nobody in particular
Requestors: chris [...] fedde.us
grousse [...] cpan.org
Cc: perl-cpan [...] bereft.net
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 20081106
  • 20081111
Fixed in: (no value)



Subject: Test failure on x86_64
Here is test output: + ./Build test t/everywhere....ok t/time..........ok 1/0 t/time..........NOK 15/0# Failed test 'localtime(-2**52)' # at t/time.t line 46. # Structures begin differing at: # $got->[0] = '46' # $expected->[0] = '44' # Failed test at t/time.t line 50. t/time..........NOK 18/0# got: 'Mon Jan 25 12:18:46 -142711421' # expected: 'Mon Jan 25 12:11:44 -142711421' # Looks like you failed 2 tests of 33. t/time..........dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 15, 18 Failed 2/33 tests, 93.94% okay t/timegm........ok 1/0 # Failed test 'timelocal(localtime(-4503599627370496))' t/timegm........NOK 3/0# at t/timegm.t line 20. # got: -4503599627370074 # expected: -4503599627370496 t/timegm........ok 4/0# Looks like you failed 1 test of 25. t/timegm........dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 3 Failed 1/25 tests, 96.00% okay Failed Test Stat Wstat Total Fail List of Failed ------------------------------------------------------------------------------- t/time.t 2 512 33 2 15 18 t/timegm.t 1 256 25 1 3 Failed 2/3 test scripts. 3/60 subtests failed. Files=3, Tests=60, 3 wallclock secs ( 3.20 cusr + 0.06 csys = 3.26 CPU) Failed 2/3 test programs. 3/60 subtests failed. This happen on mandriva linux cooker, on x86_64 only, as tests pass on i586. Here is min/max check test output: gmtime_max: 67768036191676800 gmtime_min: -67768040609740800 localtime_max: 67768036191673200 localtime_min: -67768040609741360 Perl version is 5.10.0
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Mon, 10 Nov 2008 01:39:38 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Guillaume Rousse via RT wrote: Show quoted text
> Here is test output: > > t/time..........NOK 15/0# Failed test 'localtime(-2**52)' > > # at t/time.t line 46. > # Structures begin differing at: > # $got->[0] = '46' > # $expected->[0] = '44' > > # Failed test at t/time.t line 50. > t/time..........NOK 18/0# got: 'Mon Jan 25 12:18:46 -142711421' > > # expected: 'Mon Jan 25 12:11:44 -142711421' > # Looks like you failed 2 tests of 33.
It's really weird to be off by 7 minutes and 2 seconds. Show quoted text
> # Failed test 'timelocal(localtime(-4503599627370496))' > t/timegm........NOK 3/0# at t/timegm.t line 20. > > # got: -4503599627370074 > # expected: -4503599627370496
422 seconds, that's 7 minutes and 2 seconds again. Very odd. I suspect internal floating point error. Could you try the following C program? #include <stdio.h> #include <time.h> #include <stdlib.h> int main(void) { time_t have = -4503599627370496LL; time_t from_mktime; time_t Time_Zero = 0; struct tm *date; date = localtime(&have); from_mktime = mktime(date); printf("localtime said: %s", asctime(date)); printf("mktime said: %0.f, %s", difftime(from_mktime, Time_Zero), ctime(&from_mktime)); return 0; } -- 100. Claymore mines are not filled with yummy candy, and it is wrong to tell new soldiers that they are. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
On Mo. 10. Nov. 2008, 04:40:53, schwern@pobox.com wrote: Show quoted text
> I suspect internal floating point error. Could you try the
following Show quoted text
> C program?
Since I get the same error on openSUSE x86-64 (also with the latest Time-y2038-20081111) I post the result here: mktime said: -4503599627370496, Mon Jan 25 21:05:12 -142711421 HTH Bernhard
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Wed, 12 Nov 2008 02:59:56 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Bernhard Graf via RT wrote: Show quoted text
>> I suspect internal floating point error. Could you try the
> following
>> C program?
> > Since I get the same error on openSUSE x86-64 (also with the latest > Time-y2038-20081111) I post the result here: > > mktime said: -4503599627370496, Mon Jan 25 21:05:12 -142711421
What happened to "localtime said"? -- Defender of Lexical Encapsulation
On Mi. 12. Nov. 2008, 06:00:43, schwern@pobox.com wrote: Show quoted text
> What happened to "localtime said"?
err ... sorry localtime said: Mon Jan 25 21:05:12 -142711421 mktime said: -4503599627370496, Mon Jan 25 21:05:12 -142711421
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Wed, 12 Nov 2008 12:07:43 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Bernhard Graf via RT wrote: Show quoted text
> Queue: Time-y2038 > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=40765 > > > On Mi. 12. Nov. 2008, 06:00:43, schwern@pobox.com wrote: >
>> What happened to "localtime said"?
> > err ... sorry > > localtime said: Mon Jan 25 21:05:12 -142711421 > mktime said: -4503599627370496, Mon Jan 25 21:05:12 -142711421
I checked the results using the y2038 C library directly to rule out floating point inaccuracy. We have a genuine difference and I don't know which is correct or how to verify it. TZ=Europe/Berlin localtime(-4503599627370496): Mon Jan 25 21:11:44 -142711421 gmtime(-4503599627370496): Mon Jan 25 20:11:44 -142711421 What time zone are you using? -- THIS I COMMAND!
On Mi. 12. Nov. 2008, 15:08:19, schwern@pobox.com wrote: Show quoted text
> What time zone are you using?
Europe/Berlin What is this little program supposed to do? It seems not to show a time-zone's time, but actually related to the actual longitude of the location, right? ~> TZ=Europe/Berlin ./a.out localtime said: Mon Jan 25 21:05:12 -142711421 mktime said: -4503599627370496, Mon Jan 25 21:05:12 -142711421 ~> TZ=Europe/Vienna ./a.out localtime said: Mon Jan 25 21:17:04 -142711421 mktime said: -4503599627370496, Mon Jan 25 21:17:04 -142711421 ~> TZ=Europe/Zurich ./a.out localtime said: Mon Jan 25 20:45:52 -142711421 mktime said: -4503599627370496, Mon Jan 25 20:45:52 -142711421
Le Mer. Nov. 12 17:01:36 2008, GRAF a écrit : Show quoted text
> ~> TZ=Europe/Zurich ./a.out > localtime said: Mon Jan 25 20:45:52 -142711421 > mktime said: -4503599627370496, Mon Jan 25 20:45:52 -142711421
I don't know if this have any added value, but here is mine: [guillomovitch@klodia ~]$ TC=Europe/Paris ./a.out localtime said: Mon Jan 25 20:21:05 -142711421 mktime said: -4503599627370496, Mon Jan 25 20:21:05 -14271142
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Wed, 12 Nov 2008 19:23:09 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Bernhard Graf via RT wrote: Show quoted text
>> What time zone are you using?
> > Europe/Berlin > > What is this little program supposed to do? > It seems not to show a time-zone's time, but actually related to > the actual longitude of the location, right?
No, it's supposed to be local to the time zone. That you're getting such odd output is... odd. Maybe somebody decided that for times which pre-date time zones they should use solar noon time at the actual location. If you change the time to something like 1226546352 (which is now) they should all show the same time. I'm going to whip up a program to scan backwards in time and compare the results until it finds the point where this diverges. Meanwhile, if you know anyone in the 64 bit Linux world maybe you can ask them about this. Show quoted text
> ~> TZ=Europe/Berlin ./a.out > localtime said: Mon Jan 25 21:05:12 -142711421 > mktime said: -4503599627370496, Mon Jan 25 21:05:12 -142711421 > > ~> TZ=Europe/Vienna ./a.out > localtime said: Mon Jan 25 21:17:04 -142711421 > mktime said: -4503599627370496, Mon Jan 25 21:17:04 -142711421 > > ~> TZ=Europe/Zurich ./a.out > localtime said: Mon Jan 25 20:45:52 -142711421 > mktime said: -4503599627370496, Mon Jan 25 20:45:52 -142711421
-- Hating the web since 1994.
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Wed, 12 Nov 2008 19:24:31 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Guillaume Rousse via RT wrote: Show quoted text
> Queue: Time-y2038 > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=40765 > > > Le Mer. Nov. 12 17:01:36 2008, GRAF a écrit :
>> ~> TZ=Europe/Zurich ./a.out >> localtime said: Mon Jan 25 20:45:52 -142711421 >> mktime said: -4503599627370496, Mon Jan 25 20:45:52 -142711421
> I don't know if this have any added value, but here is mine: > [guillomovitch@klodia ~]$ TC=Europe/Paris ./a.out > localtime said: Mon Jan 25 20:21:05 -142711421 > mktime said: -4503599627370496, Mon Jan 25 20:21:05 -14271142
It said -14271142? That's a genuine bug in your system, localtime() and mktime() should round trip. You'll want to report that to your OS vendor. -- 185. My name is not a killing word. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
On Mi. 12. Nov. 2008, 22:23:45, schwern@pobox.com wrote: Show quoted text
> Maybe somebody decided that for times which pre-date time zones they > should > use solar noon time at the actual location.
That makes sense. So it's not a bug, it's a feature. ;-) Show quoted text
> If you change the time to something like 1226546352 (which is now) > they should > all show the same time.
Correct.
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Thu, 13 Nov 2008 11:25:16 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Bernhard Graf via RT wrote: Show quoted text
>> Maybe somebody decided that for times which pre-date time zones they >> should >> use solar noon time at the actual location.
> > That makes sense. So it's not a bug, it's a feature. ;-)
A pretty clever feature. Well, the idea of exactly testing the results of localtime() was always dodgy at best. I'll give them an epsilon of an hour or two which should clear things up. -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
On Thu Nov 13 14:25:50 2008, schwern@pobox.com wrote: Show quoted text
> Bernhard Graf via RT wrote:
> >> Maybe somebody decided that for times which pre-date time zones
> they
> >> should > >> use solar noon time at the actual location.
> > > > That makes sense. So it's not a bug, it's a feature. ;-)
> > A pretty clever feature.
Thinking on it again... those tests are set to US/Pacific, not a specific city. There's no obvious "solar noon" for a region as large as that. I wonder what they're using.
Here's another data point. This looks like a similar problem: $ 14:26:35 cfedde@floss:~/src/Time-y2038-20081111 perl t/time.t ok 1 - use Time::y2038; ok 2 - gmtime(0) ok 3 - localtimetime(0) ok 4 - gmtime(2**30) ok 5 - localtimetime(2**30) ok 6 - scalar gmtime(0) ok 7 - scalar localtime(0) ok 8 - scalar gmtime(2**30) ok 9 - scalar localtime(2**30) ok 10 - gmtime(2**52) ok 11 - gmtime(-2**52) ok 12 ok 13 ok 14 - localtime(2**52) not ok 15 - localtime(-2**52) # Failed test 'localtime(-2**52)' # at t/time.t line 46. # Structures begin differing at: # $got->[0] = '46' # $expected->[0] = '44' ok 16 - localtime() w/dst ok 17 not ok 18 # Failed test at t/time.t line 50. # got: 'Mon Jan 25 12:18:46 -142711421' # expected: 'Mon Jan 25 12:11:44 -142711421' ok 19 ok 20 - void context warning ok 21 - prototype(gmtime) ok 22 - gmtime() ok 23 ok 24 ok 25 ok 26 ok 27 - void context warning ok 28 - prototype(localtime) ok 29 - localtime() ok 30 ok 31 ok 32 ok 33 1..33 # Looks like you failed 2 tests of 33. the C code above returns: $ 14:26:57 cfedde@floss:~/src/Time-y2038-20081111 ./schwern localtime said: Mon Jan 25 13:11:48 -142711421 mktime said: -4503599627370496, Mon Jan 25 13:11:48 -142711421 $ 14:27:31 cfedde@floss:~/src/Time-y2038-20081111 uname -a Linux floss 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux
Hi folks, I've finally got this problem licked and it tests out ok on 64 bit machines. I've added some fuzz of a couple hours to the distant localtime() tests and also made timelocal() and timegm() make better use of the system functions so they should round trip with localtime() and gmtime() better. Please try this alpha and report. http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/Time-y2038-20100213.0504_02.tar.gz
On Sat Feb 13 16:05:22 2010, MSCHWERN wrote: Show quoted text
> Hi folks, > I've finally got this problem licked and it tests out ok on 64 bit > machines. I've added some fuzz of a couple hours to the distant > localtime() tests and also made timelocal() and timegm() make better > use > of the system functions so they should round trip with localtime() and > gmtime() better. > > Please try this alpha and report. > http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/Time-y2038- > 20100213.0504_02.tar.gz
I tried this but got some errors during the build. Eventually, I got the tests passing, but I'll provide the details on the other issue here. [11:13 Time-y2038-20100213.0504_02]$ perl ./Build.PL Checking whether your kit is complete... Looks good Checking prerequisites... Looks good Creating new 'Build' script for 'Time-y2038' version '20100213.0504_02' [11:13 Time-y2038-20100213.0504_02]$ ./Build Probing time.h capabilities. You may see some C errors, that's ok. try.c: In function ‘main’: try.c:9: warning: assignment discards qualifiers from pointer target type Failed to re-load 'Local::Module::Build': Can't locate Local/Module/Build.pm in @INC (@INC contains: _build/lib /home/bsb/perl/lib /home/bsb/japh /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 29) line 1. Building a program to test the range of your system time functions... cc -Iy2038 -I/usr/lib/perl/5.10/CORE -fPIC -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -o check_max.o check_max.c check_max.c:3:27: error: time64_config.h: No such file or directory error building check_max.o from 'check_max.c' at /usr/local/share/perl/5.10.0/ExtUtils/CBuilder/Base.pm line 112. $ ./Build test # fails the same as ./Build I looked for time64_config.h, but think it was the Local::Module:Build failure not creating it: ./inc/Local/Module/Build.pm: $self->munge("y2038/time64_config.h.in" => "y2038/time64_config.h"); I re-ran with: $ PERL5LIB=inc ./Build $ ./Build test [..] All tests successful. I'm using Ubuntu Jaunty's perl. $ pmvers Module::Build 0.3 $ pmvers ExtUtils::CBuilder 0.27 $ perl -v This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi Happy to provide more info
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Sun, 14 Feb 2010 17:00:21 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Brad Bowman via RT wrote: Show quoted text
> Creating new 'Build' script for 'Time-y2038' version '20100213.0504_02' > [11:13 Time-y2038-20100213.0504_02]$ ./Build > Probing time.h capabilities. > You may see some C errors, that's ok. > try.c: In function ‘main’: > try.c:9: warning: assignment discards qualifiers from pointer target type > Failed to re-load 'Local::Module::Build': Can't locate > Local/Module/Build.pm in @INC (@INC contains: _build/lib > /home/bsb/perl/lib /home/bsb/japh /etc/perl /usr/local/lib/perl/5.10.0 > /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 > /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at > (eval 29) line 1.
Damn. I got that on FreeBSD, too. There was some sort of bug in Module::Build's @INC recording so it doesn't remember that 'inc' was in the path when Build.PL was run. I don't know when this was fixed. I'll find out. -- "I went to college, which is a lot like being in the Army, except when stupid people yell at me for stupid things, I can hit them." -- Jonathan Schwarz
Subject: Re: [rt.cpan.org #40765] Test failure on x86_64
Date: Sun, 14 Feb 2010 18:28:59 -0800
To: bug-Time-y2038 [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Ok, new alpha should have it fixed. If its not on CPAN you can get it here. http://github.com/schwern/y2038/tarball/v20100214.1823_03
Haven't heard back from the poster. Replicated the bug on a similar machine. Assuming resolved.