Actually, Unix (at least; I can't speak to Windows) keeps all times internally in UTC and only converts to local time for display.
On Sat, Oct 25, 2025 at 8:59 AM Jon Perryman <[email protected]> wrote: > On Fri, 24 Oct 2025 16:01:50 -0500, Paul Gilmartin <[email protected]> > wrote: > > >This problem was solved long ago: <https://www.iana.org/time-zones> > >Inexplicably, IBM shuns that solution, almost pervasive elsewhere. NIH? > > IANA solution does not solve the time change problem (DST nor ST). > > Unix & Windows completely ignore the implications of that hour change. > These machines are so much slower where an hour time change goes unnoticed. > A single z/OS is many times more active and SYSPLEX makes this far more > complex. > > >>that issuing the TIMEZONE W.05.00.00 or set CLOCK=hh.mm.ss commands > should do the trick. > > Time change occurs on Sunday's at 2:00am which will go unnoticed but there > are still risks. > > Some STC's have an optional timezone specifications that can override the > z/OS timezone (e.g. CICS) for the product. If you never use them, then they > most likely won't be a problem. > > Do you avoid specifically specifying Sunday between 1AM to 2AM (e.g. > automation, job scheduler and more). For instance, does a job scheduled for > 1:30am run twice for DST and never run for ST. I would hope job schedulers > warn you but some products might not. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Jay Maynard ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
