I've been reading this dialog with some interest as I wrote many calendar and time keeping manipulation programs in the 1980's and 1990's. The code was run by a large consortium of power companies in the Northeast.
A little known tidbit is that the generation load on a power company directly effect time on analog clocks. When the generation is low (like at 4 in the morning) the clocks lose time as the generation is perhaps 57-58 cycles per second. As people wake up cook breakfast and go to work the load increases the generation increases and maybe 62-63 cycles per second. Our very simple solution to ensure that the mainframes were close to the correct time was to query NIST WWV at reasonably short intervals and issue an operator set time command to NIST time if the mainframe had drifted fast or slow by .2 seconds. I guess I should have started this little blurb with "Back in the day" but I won't. My only advice is that there are International standards (ISO) that will keep things fairly simple if used. Of course, you can trust your vendor also. ...but then they don't always follow standards that well. Good luck. Kurt (tired and retired) Oh! by the way.... I was asked to write code to deal with leap seconds way back then... The notion was to have a solution should there be a problem. ...My shared attitude on the subject is "who cares" Bring back the sundials... On Sun, Jun 22, 2014 at 6:23 PM, Paul Gilmartin < [email protected]> wrote: > On 2014-06-22, at 00:25, John McKown wrote: > > > > What I would do it look at the CONVSTCK and STCKCONV macros. They can > > translate to various display formats to STCKE internal format( CONVSTCK). > > So it is easy. Convert your date/time to an STCKE value. Do a normal 128 > > bit add of 30 minutes in STCKE value units to it. Then use STCKCONV to > > convert it back to your display format of choice. > > > CONVSTCK? CONVTOD? Whatever. > > Nitpick: I suspect this will give a 31-second delay rather than 30 if > a leap second occurs in the selected interval. But JWG doesn't believe > in leap seconds. > > But we really don't know. A while back, I ranted on IBM-MAIN about > the lack of documentation of STCKCONV/CONVTOD. Do they deal in LOCAL > time? GMT? TAI? Other? An IBM representative said that no further > documentation is needed; it's "common knowledge" what they do. IMO, > "common knowledge" is no substitute for documentation. I submitted an > RCF. It was rejected with language similar to what that IBM rep > said on IBM-MAIN. I suspect that for TOD values prior to 1972 they > deal in GMT; 1972 and later a fictitious standard of TAI minus 10 > seconds. But IBM won't say so. > > > Ref: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A9B0/88.0 > > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A7A0/30.1 > > > > Now, I can hear you asking: What is the STCKE value for 30 minutes??? > Well, > > > Rexx is great for this. And it should be a motivation for HLASM to > support 64-bit arithmetic. Either TOD or the top 64 bits of ETOD > represents microseconds without truncation. > > -- gil >
