> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Hardee, Chuck
>
> [ snip ]
>
> I have two (currently) sets of data. The data is historical. [ snip ] I need
> to be able to convert to and from local times and UTC times. And, let me say
> now, when I
> say "time", I mean a timestamp consisting of yyyy/mm/dd hh:mm:ss.tttttt, that
> is year, month, day,
> hour, minutes, seconds and microseconds.
>
> I currently have routines to determine the range of Daylight Savings Time, or
> as some of indicated,
> Summer Time, and other names, all boiling down to the same thing.
>
> I have a mechanism to obtain the offset to UTC as a signed value indicating
> before or after UTC, for
> example. On the East Coast of the US, the UTC offset is -5 hours (non-DST)
> and -4 hours (DST), meaning
> behind UTC.
>
> The issue becomes when I have a local time that falls outside of the DST
> period but when adjusted for
> UTC falls within the DST period. Does it get adjusted?
What do you mean by "adjusted for UTC"? I believe it is "by definition" that a
specific time cannot be simultaneously "Standard time" and "Daylight Saving
time"; it is either one or the other, and its representation in UTC will not
change that.
> For example, given a time of 01:59:59.999999 on the day of the switch to DST,
> when the UTC adjustment
> is made (assuming my US East Coast example), the time would be
> 06:59.59.999999. Now, the local time
> was outside the DST range, but when adjusted to UTC it falls within the DST
> range. Does the adjusted
> UTC time get adjusted for DST?
No. Only the local time gets adjusted. At "spring forward" time, the next
"tick" after 01:59:59.999999 EST is 03:00:00.000000 EDT, while the next "tick"
after 06:59:59.999999 UTC is 07:00:00.000000 UTC. When converting from UTC to
local time at "spring forward" time, you create a gap in the sequence of local
time stamps.
> And then, having gone thru the narration for local to UTC, a similar
> questions exists for UTC to local, and then similar questions regarding the
> other end of the DST
> period.
Again, it is only the local time that gets adjusted. At "fall back" time, the
next "tick" after 01:59:59.999999 EDT is 01:00:00.000000 EST, while the next
"tick" after 05:59:59.999999 UTC is 06:00:00.000000 UTC. But one might hope
that the recorded local time stamps would continue only forward, so that
02:00:00.000000 EST would immediately follow 01:59:59.999999 EDT. If that's
the case when converting from local time to UTC at "fall back" time, you create
a gap in the sequence of UTC time stamps.
But when converting from UTC to local time at "fall back" time, you create
duplicate local time stamps if there is not already a suitable gap in the
sequence of UTC time stamps. In that case you'd need to devise a means to keep
the duplicate local time stamps in the correct order.
-jc-
**********************************************************************
Information contained in this e-mail message and in any attachments thereto is
confidential. If you are not the intended recipient, please destroy this
message, delete any copies held on your systems, notify the sender immediately,
and refrain from using or disclosing all or any part of its content to any
other person.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
