Paul Gilmartin wrote:
IBM utilities are moving glacially in the rignt direction. A conspicuous
laggard is ISPF PDS member time stamps. There ought to be a PARMLIB option
allowing installations to choose to store those in UTC, notwithstanding
setting of the system time zone otherwise.
A collateral problem is that if I TRANSMIT a file on Friday before the
onset or end of Daylight Saving Time and someone RECEIVEs it on the
Monday following, the time stamp is skewed by an hour. This needs to
be fixed by making the Local<->UTC conversion Daylight Time savvy.
But WAD; it was apparently not a design requirement that the results
be correct.
In z/OS, it is impossible to properly convert a historical time stamp
between UTC and the then-current local time. In the most pathological
case, the 'SET TIME or SET TIMEZONE' commands could be issued on
different LPARs with different values every few seconds to change the
local date/time to values that are essentially unpredictable. If you
wish to be able to display local time, you must save local time.
We spent a considerable amount of time discussing how this issue
affected one of our software products and came to the conclusion that we
must maintain time stamps in both UTC and local formats in all cases.
There are no conversions except to use the current local date/time
offset and leap seconds values to derive the local date/time from UTC
when first storing a time stamp. All subsequent references to the time
stamp will refer to either the local part or UTC part depending on the
current processing requirements.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
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
