> Does it also fail to provide a table of historical CVTLDTO values? > If so, it's an hour off a mere few months ago, on the other side of > the Daylight Saving Time boundary; so much worse. > > > If your program requires historical correctness, it could maintain a
> > historical table of leap second values, and compute the difference > > between the number of leap seconds in effect at the date of your > > historical TOD value and the number of leap seconds for the > > current date. Convert that number of seconds of difference to timer > > units (by multiplying by 1,000,000 (microseconds per second) * > > 4096 (timer units per microsecondsecond) ). Add this number of > > timer units to your historical time stamp, and pass the result to > > STCKCONV. > > > Why should each programmer need to do this? Some of them are sure to > get it wrong. Better such a table should be incorporated in STCKCONV. > > But, have you checked the source code? My test program shows > (CONV is my macro to use > STCKCONV STCKEVAL=&STCKEVAL,CONVVAL=PK, x > DATETYPE=YYYYMMDD,TIMETYPE=DEC,MF=(E,SPLIST) > to convert then format and print the STCKE argument.) > * > * Circa December, 2008 Leap Second 24, per PoOp. > * > CONV =X'00C3870CB9BB5FFFFFFFFFFFFFFFFFFF' > CONV =X'00C3870CB9BB60000000000000000000' > Prints: > 2009-01-01 00:00:23.999999 > 2009-01-01 00:00:24.000000 > ... off by 24 seconds because our site runs with CVTLSO=0 because > too much software from vendors (including IBM) yields inconsistent > results with CVTLSO set correctly. Well, I did check the code, but not carefully enough. The code in question is used by both the TIME macro when LINKAGE=SYSTEM is specified, and the STCKCONV macro. Upon closer inspection, the code dealing with CVTLSO and CVTLDTO is on a path used only for TIME with LINKAGE=SYSTEM. STCKCONV does not do anything with CVTLDTO and CVTLSO, or attempt any kind of leap second or time zone adjustment. The caller must make any such desired adjustments before calling STCKCONV. > * > * End of the World. > CONV =X'01000000000000000000000000000000' > CONV =X'01FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF' > Prints: > 1900-01-01 00:00:00.000000 > 2042-09-17 23:53:47.370495 > ... showing mostly that STCKCONV (as of z/OS 1.13) has not yet > implemented the (proposed) use of the high byte of STCKE when > the ETOD clock wraps. In z/OS 2.1, STCKCONV does handle x'01' on the high byte of an STCKE value (thanks to Peter Relson). > * > TIME STCKE,CLK5,LINKAGE=SYSTEM,MF=(E,W.TPLIST) > CONV CLK5 > * > STCKE CLK5 > CONV CLK5 > Prints: > 2014-07-09 23:05:44.299901 > 2014-07-09 23:05:44.299921 > ... the job log shows "17.05.44 JOB05935 $HASP395 HELLO ENDED" > Hmmm... Our CVTLDTO here in sunny Colorado today is -6 hours. > It appears that STCKCONV is *not* applying CVTLDTO. (And I've > learned that the conversion took 20 microseconds.) > > But, I believe that when programmers as sophisticated as you and > I (I'll not presume to call myself in your class) can have > misconceptions about the operation of STCKCONV, Peter Relson is > wrong to call it "common knowledge", not needing further explanation. > > It does give correct GMT for dates prior to 1972. Perhaps someone > merely forgot to update it when UTC came on the scene. I don't know that I have ever been considered to be a "sophisticated programmer" - mostly known around IBM as a dump reader. I haven't ever used STCKCONV - it did not exist until SP4.1.0 (around 1990), so the code I have worked on which needs to do timestamp conversion (mostly code which runs under IPCS) instead uses the BLSUxTOD services supplied by IPCS. The BLSUxTyD services also do not do any leap second or time zone adjustments. I just looked into STCKCONV today to try to answer your questions while Peter is on vacation. If you feel that the STCKCONV documentation should be updated to explicitly say that STCKCONV does not do any leap second or time zone adjustments, I would suggest submitting a Reader's Comment Form. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
