> The Dignus runtime main() start-up from a BATCH or TSO start examines the CVTTZ value and constructs a TZ that offers the proper offset
Good approach IMHO. I know I tried doing that and ran into some sort of issue. The fact is that the LE approach is poor. I don't say that because I am a configuration genius and could have done better. I say that because in 8 years of supporting an STC written in C++ we encountered customer after customer with whom we had the following dialog: "Your product is broken. The times are wrong." "You just need to set the local time offset in /etc/whatever." "No, we have the local offset. Every other product gets it right. Your product is broken." "That's in CLOCKxx. You need to set the local time zone variable with ENVAR in /etc/whatever." "Why should we have to do that. Every other product gets it right. Your product is broken." The default for USS startup should be the offset in SYS1.PARMLIB(CLOCKxx), and let UNIX-sophisticated customers override that as they wish. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas David Rivers Sent: Thursday, August 15, 2019 1:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local time in C on z/OS Phil Smith III wrote: >I have a C POSIX application that writes timestamps on its output. It's always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I thought maybe I could fix it. > > > > The fundamental problem with "local time" is the definition of "local". If we make the assumption that the machine clock is kept in UTC (GMT), then the local time is simply the different from UTC to where one might be at that moment on the globe. Now - consider the problem of a terminal connected to a fairly remote system. The user may consider himself in a different timezone from the system; hence his idea of "local" is different than the, say, the operator console which happens to be physically adjacent to the actual hardware device that keeps track of the time. This is why UNIX/POSIX has the TZ environment variable - one user can set a different timezone than another. And this is also why a "global" setting of TZ in, say, /etc/rc isn't always the right idea. You may have multiple users in multiple timezones. Some systems might go as far as keeping a database of sorts for terminals, and having the /etc/rc script make a good guess as to what the proper TZ setting might be. This is also why the ssh (and other remote-connect-over-the-internet protocols) have mechanisms for passing the value of the TZ environment variable to the remote shell. The user connecting can say "hey - when you connect, set this to be my TZ value." All that is well and good - but then we run into the problem of programs being dub'd without going thru the typical UNIX start-up... what TZ should they get then? The Dignus runtime main() start-up from a BATCH or TSO start examines the CVTTZ value and constructs a TZ that offers the proper offset from UTC (again, this assumes the machine's clock is set to UTC and that CVTTZ is properly set.) This basically gives you a "local time" for the machine, the user would need to set TZ to something else if they are not in the same locality as the machine. Under a USS start-up, we inherit the TZ environment variable from the BPX environment. Thus - the entire question about "what time is it" is totally answered when you can reliably answer the question of "where are you?" - Dave Rivers - -- riv...@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
