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 guess my assertion of negative being legal is technically correct (the error situation) but arguably misleading; however I stand by my "generally work." https://stackoverflow.com/questions/29958333/negative-value-returned-by-time and scroll down to the last answer, the answer Apr 30 '15 3:28 by Cubia. I recall using negative time_t's but cannot remember the context; it may not have been on Z. https://www.epochconverter.com/ returns a time in 1922 for -1500594880 and yes, -1 for 1969-12-31 23:59:59 gmt. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, July 20, 2017 3:43 PM To: [email protected] Subject: Re: Curious about IBM time conversion example program 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. 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
