On 07/20/2017 10:04 PM, Paul Gilmartin wrote:
> On Thu, 20 Jul 2017 16:58:11 -0700, Charles Mills wrote:
>
>> Far be it from me to try to interpret the POSIX standards. It's definitely
>> signed on z/OS.
>>
>> typedef long time_t;
>>
>> Why waste a bit if you are not going to support negative? Making it unsigned
>> would have put off the Year 2038 problem an additional 68+ years.
>>
> I had a similar feeling about STCKE. If the 128-bit value returned
> by STCKE is treated as unsigned, it spans 1900 CE to about 38434 CE.
> If it were to be treated as signed it would be about 16367 BCE to
> 20167 CE. In this list, I argued for the signed representation,
> feeling that representing dates in the 19th century CE has more
> practical use than representing dates in the 202nd century CE.
> IBM employees said it's too late to make that choice -- code already
> extant relies on STCKE's returning a value to be treated as unsigned.
>
> (Computations approximate -- not to be used in life-and-death situations.)
>
> -- gil
>
> ...
But arguing that the z-architecture clock format should support dates
prior to 1900 CE implies that storing date-time values in a
machine-specific time-stamp format would be desirable.
Why would anyone ever choose to represent or store historical event time
stamps prior to 1900 CE using a date format that is vendor-specific and
even machine-architecture-specific, and with a resolution that is
totally inappropriate for historic events considering the accuracy of
clocks of those times? Machine-independent date-time formats are a much
wiser choice for long-term storage of historic time stamps, or as a
"universal" date-time format to use as an intermediate form when
converting between two other date-time formats.
Joel C. Ewing
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
