On Mon, 8 Nov 2010 10:40:29 -0600, Mark Zelden wrote:
>On Mon, 8 Nov 2010 16:33:08 +0000, Eric Bielefeld<[email protected]>
>wrote:
>
>>I have another question on the time change. I was just looking at one of
>the systems we had down for an hour for the time change. I noticed that the
>OMVS time was never reset. The /SYSTEM/etc/profile dataset has:
>>
>>TZ=EST5EDT
>>export TZ
>>
>>This hasn't been changed. Does this matter? According to the attributes,
>this file hasn't been changed for over 5 years, so I assume it hasn't caused
>any adverse problems, or else it would have been changed every fall and spring.
>>
It's probably correct; leave it alone.
>Why do you think the time wasn't changed? What are you looking at?
>Note that there are multiple considerations / places to change within or for
>z/OS unix when it comes to what local time is used (search the archives).
>
In the string "EST5EDT", the "5" means use an offset from UTC
of -5 hours in the winter, and label messages with the timezone
"EST". The "EDT" means use an offset one hour greater during the
summer and label messages "EDT". The boundary between winter
and summer is according to US conventions. The operation is
US-centric; locales with different boundaries must use a longer
string indicating the dates and hours of the boundaries.
The paradigm of an offset from UTC to civil time which must be
changed semiannually is adverse. It's better to have a function
which takes a UTC value, past, present, or future, as its argument
and returns the corresponding civil time. Such a function needs
to be updated only when legislation alters the boundaries.
And the concept of exactly two time zones, "GMT" and "LOCAL" is
parochial. There are 24 zones (actually far more), and a proper
conversion function has two arguments:
localtime( UTC, zone )
... dealing with the need to operate various LPARs with
different local time zones but the same STP. In fact, it
even allows z/OS processes within the same LPAR to operate
with different time zones as easily as:
u...@mvs:130$ TZ=GMT0 date
Mon Nov 8 19:29:06 GMT 2010
u...@mvs:131$ TZ=MST7MDT date
Mon Nov 8 12:29:09 MST 2010
This is implemented in z/OS Unix System Services, so programmers
and administrators needn't think in terms of a semiannual
"change". It just works. However, the z/OS function is
ignorant of the legislated boundaries at 2007 and 1986 which are
handled properly by most other UNIXen.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
