One major consideration should be who sets the time zone. Many mainframes support users in multiple time zones. So ideally the mainframe should be set to UTC then the macro should convert to the local time of the individual application / user.
On Fri, Dec 28, 2018 at 1:47 PM Peter Relson <rel...@us.ibm.com> wrote: > > I shouldn't have included "TIME" among the services I mentioned because > that's "current", not "historic" (so only has to deal with "current" leap > seconds) and because it does not let you choose STCK as the "zone" -- you > must choose between local and UTC, both of which are defined with respect > to leap seconds. > Thus it must handle leap seconds, but also is not in the position of > needing update for a "new" leap second. > > And, in case you're wondering, at the "instant" of bringing in a new leap > second, there are various approaches in play that customers choose to > adopt and I doubt that it is deterministic on which side of the fence you > would necessarily fall if you used some service such as TIME (or if you > did it yourself) -- perhaps the STCK was done "just before" but reference > to CVTLSO was "just after". Something similar could happen with respect to > time zone offset changes. > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
