On 06/07/2013 09:05 AM, Paul Gilmartin wrote:
On Thu, 6 Jun 2013 23:48:46 -0700, Ed Jaffe wrote:
DS9TIME DS XL6 Number of microseconds since
* midnight, local time, ...
Did I fail to read this correctly previously? Now that I look more
carefully, it seems to be saying that the field stores a counter that
is reset to 0 each midnight, local time, and counts uniformly until
the next midnight. So on most days, it will reset after 24 hours
worth of microseconds. On the day of the Fall Daylight Saving Time
boundary, it will reset only after 25 hours' worth of microseconds;
on the day of the Spring Daylight Saving Time boundary, it will
reset after only 23 hours' worth of microseconds. No ambiguity,
but tricky to convert to local time. And the best way for allocation
to compute the needed value is to save the (E)TOD value each
midnight and subtract from the (E)TOD value at the time of
allocation.
Are there locales where the Daylight Saving Time boundary
occurs at midnight, or spans midnight so there might be two
midnights, an hour apart? Or none, in the Spring?
Leap seconds? If one is concerned with microsecond precision, one
needs to be concerned with how leap seconds are treated.
-- gil
I believe the above description of variance of range of
microseconds-from-midnight to 23 or 25 hours only applies if you
dynamically change your offset at DT<->ST transitions without an IPL.
For those still doing an IPL to change the offset via CLOCKnn, z/OS is
no doubt just going to calculate and initialize the
microseconds-from-midnight value at IPL time on the assumption this is a
normal day with 24 hours, resulting in repeat offset-from-midnight time
values during the DST->ST fall-back hour if you IPL at 0200 local time
that day -- perhaps another good argument why installations that have
not yet done so should consider dynamic time offset changes.
I would argue that whenever one wants to use local time to record a time
value that will potentially be used for later ordering of events, that
the local-time offset should always be recorded along with the local
time value to remove all ambiguity and eliminate the need for
applications to have detailed historical knowledge about arcane local
DST transition rules in order to compare time values..
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
