> Subtract? Sort of. My impression -- and I would be happy if someone could definitively confirm or correct me -- is that leap seconds are of course subtracted from the TOD value, but the value in CVTLSO is negative, so adding CVTLSO subtracts the leap second count. On the test LPAR that I am currently looking at CVTLSO is zero, so that's not much of a clue. http://www.longpelaexpertise.com/toolsTOD.php supports my thinking.
> how does one ensure that CVTLSO hasn't changed I don't know. How DOES one change CVTLSO? I just searched MVS System Commands and Init & Tuning for <leap> and <CVTLSO> and got no hits. Specifically, is there a supported way of changing it "suddenly"? Google reveals that you and I had this same discussion a year ago: https://www.mail-archive.com/[email protected]/msg59183.html A more significant issue IMHO is that CVTLSO is the *current* leap second adjustment. If one is converting a timestamp from ten years ago -- say from an archived SMF dataset -- how does one get the leap second offset at that time? If it changes between STCK and AG or between the start of some job and its end, then at worst one is off by one second. Adjusting a TOD from 2007 by today's offset will put you off by four seconds. For a TOD (real STCK or "computed") from 1971 you will be off by almost half a minute. Yeah, LE *could* support negative UNIX times. Would not take a great algorithmic leap. But the fact is that they don't. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Friday, November 17, 2017 6:40 PM To: [email protected] Subject: Re: A modest proposal: LE enabled HLASM + C runtime On 2017-11-17, at 18:56:20, Charles Mills wrote: > Okay, in response to absolutely no popular requests, here is how to > convert a TOD to a UNIX time: > > Add CVTLSO. There's your all-important leap seconds, affine or otherwise. > Subtract? > > ...to save a couple of cycles in the case of repetitive conversions > you could adjust that constant for CVTLSO and only do one subtract. > Taking care that CVTLSO hasn't changed midstream, which might devour the saving. BTW, how does one ensure that CVTLSO hasn't changed between the STCK and the access of CVTLSO? > ... > If the result is negative you are out of luck. The C library routines > do not support negative times (times before 1/1/1970). > I believe that (used to be) a POSIX requirement, but many non-IBM UNIXen tolerate the violation. In: http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html#tag _16_299_05 ERRORS The localtime() [CX] and localtime_r() functions shall fail if: [EOVERFLOW] The result cannot be represented. ... no mention of negative argument. This leaves the bugbear "-1", returned as an error by mktime(). But is that 1969-12-31 23:59:59. I suppose returned value is -1 but errno is
