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

Craig A. Berry wrote:
> 
> On Feb 17, 2009, at 10:50 PM, John Malmberg wrote:
> 
>> I have not yet figured out how to fix this, but the localtime64_r 
>> wrapper seems to only sometimes call the vms.c localtime, and 
>> gmtime64_r is configured to never call it.  This is done by logic in 
>> time64_config.h which is not modified by the VMS Configure.com procedure.
> 
> Yes, there is currently no way to turn off the time64 stuff entirely but 
> it might be better to try to get it working than to create configuration 
> options to disable it.
> 
>> These routines need to always call the wrappers in vms.c,
> 
> That may not be the best approach as I think you'd no longer get the 
> extended range provided by the time64 versions.
> 
>> or those routines need additional logic for VMS, as there is a vmsish 
>> time pragma that controls if the time functions results are in UTC or 
>> localtime.
> 
> That's probably better and shouldn't be too intrusive.  I think it would 
> just be a matter of putting something like
> 
> # ifdef VMSISH_TIME
>   if (VMSISH_TIME) when = _toutc(when); /* Input was local time */
> #  endif
> 
> in two or three places.  The _toutc and _toloc macros would need to be 
> moved from vms.c to vmsish.h and given somewhat more collision-proof names.
> 
>> This is causing the failure in the vmsish.t module where it is 
>> requesting a gmtime() return of a time value that is in local time, 
>> not GMT.
> 
> Thanks for the report.  The other problem with time64 and friends is 
> that the build falls down hard on any platform that does not have a 
> 64-bit integer type.  Possibly OpenVMS VAX is the only one of those 
> that's been somewhat recently supported.  I've started looking into 
> making it use a double, but that may involve understanding more of how 
> time64 works than I care to or have time to in the near term.

As I understand it, when using the DEC/Compaq/HP VMS C compiler, 
currently time_t is by default an unsigned type, which avoids the Y2038 
issue.

I do not know how far back that goes.  All my VAX systems have been 
powered off since my move, and I have not had time to get them going.
I do not know if DeathRow would be willing to host a build environment 
for PERL on their VAX, or even if it has enough space.

On Alpha/I64, when the _USE_STD_STAT feature is enabled, several of the 
structures that use time_t values have padding in them to handle a 
future 64 bit time_t value.

The only issue with using a double to hold a time_t value may show up in 
other places in Perl if it ever tries to copy that value into an integer 
value.

I was told that while X/Open standard does not seem to prohibit a time_t 
value from being a double, in practice it is very easy to find programs 
that break if time_t values are not integer types.

So if a double is used to hold the time_t value, it probably needs to be 
a perl private type.  Which means it could also be a structure holding 
two Integer values.  I have not checked to see if a double on VAX will 
lose seconds for the upper time ranges anticipated.

-John
[email protected]
Personal Opinion Only