Every address space can run with its own value of TZ or _TZ set. The historic TIME macro does not support different time zones for different address spaces. Since I am now a dedicated user of LE environments, even in HLASM, I would use the CEEGMT subroutine (LE) to get the Lilian date (32 bit integer) and GMT seconds (64 bit float). I would actually store that information (64 bit float) in my data repository. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA31C0/2.2.5.41 You can then use CEEGMTO to get the offset to local time. But this is based on the z/OS TIMEZONE, not the TZ or _TZ environment variable. And CEEDATM to convert whichever you want into a printable character string, for display. Of course, you can convert the GMT time to local using other methods, if you really want to.
I agree that local time stinks. I tried to convince my first employer to use GMT. Like to have gotten lynched by Production Control when I printed out the date and time on job output as GMT using 24 hour military notation. They didn't much care for messages like: RAN AT 23:17:05 ON 1981-03-27 (March 27, 1981 at 6:17:05 P.M. local) On Fri, Sep 6, 2013 at 9:32 AM, Charles Mills <[email protected]> wrote: > The software in question is "reporting" z/OS security-related events so > the one time zone in which the box itself is located (or where its sysprogs > think of it as being located) is appropriate and sufficient. > > Yeah, the fact that z/OS has two completely different "systems" for > specifying the local time zone is annoying, but not my problem to solve > today. > > Customers are not really limited to two time zones, are they? You could in > theory run 5 instances of my program with five different TZ settings, right? > > I hate local time. > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Paul Gilmartin > Sent: Friday, September 06, 2013 7:18 AM > To: [email protected] > Subject: Re: Where environment variables set for batch POSIX programs? > > On Fri, 6 Sep 2013 07:05:56 -0700, Charles Mills wrote: > > > >My question is what do I tell the customers that ask "how come you > >don't get the time right without us telling you what to do with a parm > >or DD? Our MVS programs know what the local time is. What's wrong with > >your program?" I want to be able to say "you need to set TZ in > >_________ as described in _____________." > > > Yes, but do your customers' programs know what time it is in Pacific/Apia, > e.g. Many enterprises nowadays span multiple time zones; restricting > customers to two is pretty harsh. > > Cite: > http://en.wikipedia.org/wiki/Conway%27s_law > > (Or did I overlook some imputed rhetoric?) > > Simply, if either the POSIX time or the OS/360 time is set in PARMLIB, but > not both, the system should infer the one missing from the one supplied. > If both are supplied but incosistent, it should issue an informative > message. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- As of next week, passwords will be entered in Morse code. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
