Re: Time64 needs to call VMS.C gmtime() and localtime() always.

[email protected] ("Craig A. Berry")
Newsgroups perl.perl5.porters,perl.vmsperl
Message-ID <[email protected]>
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:[email protected]

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.