Michael G Schwern (sc...@pobox.com)

That's year 0 to 30873836848.  0 makes sense, the other one I have no idea.


> # system time.h limits, as JSON
 > {   "gmtime":    { "max": 42489252465868800, "min": -42489252465868800 },
 >     "localtime": { "max": 42489252465868800, "min": -42489252465868800 },

That's not a significant point either, and its troublesome that check_max is
getting different results than Configure.  Its not a hard coded hint, is it?


>> If LOCALTIME_MAX is over 2**48 could you try localtime(2**48) in C please
>> and see if the system library is at fault?
>
> tmp 107 > ./timecheck
>   0:7fffffffffffffff:      1587287-03-17 15:30:07
>   0:8000000000000000:   4293383948-10-16 08:29:52
> ======================
> Sizeof time_t = 8
>   8:7fffffffffffffff:      1587287-03-17 15:30:07
> max:  0x7fffffffffffffff      9223372036854775807
>   8:8000000000000000:   4293383948-10-16 08:29:52
> min: -0x8000000000000000     -9223372036854775808

Well that ain't right.


> gmtime 2**48
> ======================
> Sizeof time_t = 8
>   8:   1000000000000:   4292129631-11-18 10:44:16
>   0x0001000000000000          281474976710656
>
> localtime 2**48
> ======================
> Sizeof time_t = 8
>   8:   1000000000000:   4292129631-11-18 10:44:16
>   0x0001000000000000          281474976710656

That ain't right either.  Should be 1346432780-9-28.

Does Time::y2038 pass tests?

What it looks like is your time functions go wonky in an unpredictable way.
So the binary search that check_max and Configure do will hit a good slice and
get stuck in it.  Looks like this is going to have to be hard coded.  Try this 
little C program that walks through from 2**1-1 to 2**63-1 until the year
stops going up.

Hrm.  2**46 is fine but 2**48 and 2**52 are not.

What's your LOCALTIME_MIN and LOCALTIME_MAX please?  If LOCALTIME_MAX is over 
  2**48 could you try localtime(2**48) in C please and see if the system 
library is at fault?

Also please compare what Configure's LOCALTIME_MAX is with what Time::y2038's
SYSTEM_LOCALTIME_MAX is.
http://search.cpan.org/~mschwern/Time-y2038-20100216.1421_04/

Excellent, thank you.

Michael G Schwern wrote:
> Ahh, Time::gmtime tests are now too aggressive and need to be informed
> about the raised fence.  I'll fix that now.

Ok, here's the updated patch.  Just lowered the boundaries on the 
Time::gm/localtime tests.  Passes all tests here.
http://github.com/schwern/perl/commit/88e23862cae804dd8ffbb32243902c29d2ff89fd.diff


PS  I discovered that if you stick a .diff on the end of a github commit URL 
it'll give you a raw diff.

I messed up the warning suppression in the test.  I put out so many versions 
of the patch I kind of lost track.  The versions on 
http://github.com/schwern/perl y2038-min branch and in perlbug are correct.

The proper line is:

     local $SIG{__WARN__} = sub {};

Because you can't predict which message will come out (failed, too small or
too big).  I suppose it could be tightened up by checking for /\Qtime(/ in the 
warning but I'm not worried at this point.


> . . .
> lib/Time/gmtime................................................Can't
> call method "sec" on an undefined value at ../lib/Time/gmtime.t line
> 25.
> # Looks like you planned 109 tests but ran 1.
> FAILED--expected 109 tests, saw 1
> lib/Time/localtime.............................................Can't
> call method "sec" on an undefined value at ../lib/Time/localtime.t
> line 25.
> # Looks like you planned 109 tests but ran 1.
> FAILED--expected 109 tests, saw 1
> lib/Unicode/UCD................................................ok
>
> so we're not quite there yet. I'm going to see what I can see but am
> not in a position to make promises about when.

Ahh, Time::gmtime tests are now too aggressive and need to be informed about
the raised fence.  I'll fix that now.