> What I have against (E)TOD is that IEBCOPY got leap seconds wrong > until they resolved my APAR by converting to TIME.
That's an IEBCOPY issue. If TIME STCKE doesn't do adjustments, then *that* is the issue, not ETOD itself. I certainly hope that if IBM starts using ETOD for timestamps that they will do so through a documented system interface, not RYO. What would be really nice would be if they included both UT* and the zone in the new timestamp format. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Paul Gilmartin [[email protected]] Sent: Monday, April 27, 2020 1:29 PM To: [email protected] Subject: Re: Friday OT, cheerful program for gloomy times On Mon, 27 Apr 2020 17:10:54 +0000, Seymour J Metz wrote: >> I hope not. > >What do you have against ETOD? > >> TIME macro > TIME STCKE,foo > >Or doesn't that do the adjustments? > I believe it does not. I believe TIME LOCAL and TIME GMT do. I believe STCKCONV and CONVTOD do not. I am confident that before TOD rolls over TIME will be using ETOD. What I have against (E)TOD is that IEBCOPY got leap seconds wrong until they resolved my APAR by converting to TIME. And back to David's report on the OP's BIO.TXT. That uses two different leap year formulae. Neither reports an error for 1900.0229. Rexx DATE() reports an error (though not very lucidly). The moral is, "Trust the experts; don't RYO (as IEBCOPY once did)." -- 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
