On Feb 19, 2009, at 8:55 AM, John Malmberg wrote:

Malmberg wrote:
Thomas Pfau wrote:

Current definition from Compaq C V6.4-005 on OpenVMS VAX V7.3:

typedef unsigned long int __time_t;
So VMS Perl should be good to 2106 if just use the wrapper routines in VMS.C.

That's better than failing in 2038, but if you were doing calculations for a 99-year lease you'd already be in trouble today. The time64 code takes things to a somewhat silly extreme by insisting on using a 64-bit integer for year as well as for time_t, thus moving the year limit beyond the 2 billion point. I have no idea what the practical application of that is, but there are advantages to extending the range by centuries rather than decades.

I think for VMS, we either must always use the wrappers in VMS.c or we should retire the wrappers in VMS.c in favor of time64.c and not maintain both.

We're now always using the VMS-specific code in vms/vms.c, but there's no way to avoid maintaining both. On OpenVMS Alpha and I64, we now use the time64 code but make it depend on our home-grown gmtime() to do the work of the C<vmsish 'time'> pragma:

http://perl5.git.perl.org/perl.git/commit/ec4d613

That fixes the lib/vmsish.t test failure. Time64 was already using our localtime() and its preference for using its gmtime() instead of ours doesn't appear to be that strong and it appears to work ok with ours. The tests of extended ranges in t/op/time.t still pass when using our own gmtime().

On OpenVMS VAX, and any other platform that does not have a 64-bit integer type available, we now skip the time64 code completely:

http://perl5.git.perl.org/perl.git/commit/7f33619

That rescues the build but leaves you with whatever time range your system can give you, so OpenVMS VAX will be fine until it needs to deal with years beyond 2106. Not sure if there are any other affected platforms. It might be possible to adapt the time64 algorithm to work with a double for time_t and a 32-bit integer for tm->tm_year, still giving an extended range well beyond anything of interest to human beings. I started down that path but had other fish to fry and my simulated VAX takes a day to build Perl and another couple of days to run the test suite, so I set it aside.
________________________________________
Craig A. Berry
mailto:craigbe...@mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Reply via email to