On Tue, 28 Oct 2025 14:41:57 -0500, Jon Perryman wrote: > >Even in the Unix world this is not always true. For instance, repeating events >in a calendar where global participants are not sharing the event and have >their own unique event. You don't get a warning about time changes > True. It would be better to share the event.
>For z/OS system products, IANA is irrelevant. z/OS, CICS and ??? allow for 1 >local timezone and planning for time change may be needed. Certainly the >impact is far less at 2:00am Sunday than during the 2:00pm on Thursday but the >possibility exists. > There are more than two timezones that z/OS supports/ >> Nothing changes, neither system control blocks nor code. >> at 02:00 on that Sunday morning. > >Clearly you don't understand the complexity of time change and the system. For >instance, job abc must start at 2:00am to guarantee is completes by 6:00am. >Does the job scheduler start it at 1:00am or do you accept that the job >completes after 6:00am. > Enter 6:00am in struct tm; call mktime; subtract 4*60*60 seconds; call localtime. But this is best done in UTC because 0200 occurs twice next month. >Just because you don't understand the problem doesn't mean the problem does >not exist. > The problem exists; z/OS deals poorly with it. >>a system clock value and a timezone yields identical result for identical >>input regardless >>when it is called. > >Sunday 4:00am minus 1:00am can be 2, 3 or 4 hours if using local time to >calculate. > This is best done using UTC, not local. >>z/OS should awaken to this fact, well known everywhere else in the IT world, > >ROTFLOL, the rest of the world has a single environment (processes and >threads). z/OS does not have a single environment (CICS, IMS, TSO, batch and >more). Implementing localtime in z/OS has never been a priority. Customers >needing this have written their own implementation. Simply put, local time is >not a priority because customers can easily implement their own solutions >which could include IANA. > ??? z/OS can be excused for doing it poorly because users could do it better with considerable redundant effort. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
