On 21/07/2017 6:43 AM, Paul Gilmartin wrote:
On Thu, 20 Jul 2017 14:33:58 -0700, Charles Mills wrote:
Yes, negative UNIX times are legal and generally work.
I had understood that negative time_t values are illegal but generally work.
The closest I can find in POSIX is:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html#tag_16_329_04
RETURN VALUE
The mktime() function shall return the specified time since the Epoch
encoded as
a value of type time_t. If the time since the Epoch cannot be represented,
the function
shall return the value (time_t)-1 [CX] [Option Start] and set errno to
indicate the
error.
Negative Unix times using C time_t and related functions won't work. But
Java supports them and with far greater magnitude than a signed 32-bit
integer.
https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html
static Instant EPOCH // Constant for the 1970-01-01T00:00:00Z epoch
instant.
static Instant MAX // The maximum supported Instant,
'1000000000-12-31T23:59:59.999999999Z'.
static Instant MIN // The minimum supported Instant,
'-1000000000-01-01T00:00Z'.
Should I assume that mktime( 1969-12-31 23:59:59 ) returns (time_t)-1 and does
not set ERRNO? I had understood that the z/OS XLC standard time functions
report
an error on an input negative time_t.
But a shift -- arithmetic, not logical! -- of a negative number works, except
it sometimes ends up off by one, which is not going to be a huge problem here,
right? One microsecond.
It truncates correctly toward -∞, not toward 0. "Off by" is in the eye of the
beholder, and
irrelevant because TOD values are unsigned.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
