On 06/28/2014 01:53 PM, Hardee, Chuck wrote: > Doesn't help, sorry. > > Given all the answers I've had so far, all pointing to things implying > real-time conversion of timestamps, I think it is clear that I haven't stated > my need very well. > > I have two (currently) sets of data. The data is historical. I have no > control on how the data is produced, it's from a vendor product which shall > remain nameless and is irrelevant. In the previous version of the product, > both sets of data were saved with local times. In the current product, one > set is saved in UTC, the other in local. The next version will save both sets > of data in UTC. That being said, 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? > > 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? 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. > > I hope this better explains what I am looking for. > > Chuck > > > Charles (Chuck) Hardee > Senior Systems Engineer/Database Administration > CCG Information Technology > Thermo Fisher Scientific > 300 Industry Drive > Pittsburgh, PA 15275 > Direct: 724-517-2633 > FAX: 412-490-9230 > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Mike Schwab > Sent: Saturday, June 28, 2014 12:49 PM > To: [email protected] > Subject: Re: Local Time conversion to/from UTC Time > > Sometimes it helps to see the whole word in a map. > http://www.worldtimezone.com/index24.php > > On Sat, Jun 28, 2014 at 11:26 AM, Hardee, Chuck > <[email protected]> wrote: >> Yes, I have spent a lot of time there going thru the information on the web. >> I could have easily missed what I was looking for. I will have to go back >> thru it and read the compressed files with better scrutiny. >> >> Charles (Chuck) Hardee >> Senior Systems Engineer/Database Administration >> CCG Information Technology >> Thermo Fisher Scientific >> 300 Industry Drive >> Pittsburgh, PA 15275 >> Direct: 724-517-2633 >> FAX: 412-490-9230 >> [email protected] >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of John McKown >> Sent: Friday, June 27, 2014 9:26 PM >> To: [email protected] >> Subject: Re: Local Time conversion to/from UTC Time >> >> On Fri, Jun 27, 2014 at 5:28 PM, Hardee, Chuck < >> [email protected]> wrote: >> >>> John, >>> >>> I am in the process of writing a program that is reading several files. >>> Some of the files have dates in local and some have dates in UTC. >>> I want to be able to move between the two time bases as needed. >>> I don't envision the program reading files from differing time zones at >>> the same time, but the program could be reading files from any country in >>> the world. >>> Currently I'm concentrating on the US so a US based solution would be fine >>> for the moment. >>> >>> Where I can't seem to get my head to go is related to Daylight Savings >>> Time (DST). >>> If, for instance, the locale is the east coast of the US, the UTC >>> adjustment would be -05:00, 05:00 UTC is 00:00 local. If the local time is >>> 02:00 on the day of the switch in the spring, that's easy, subtract the >>> signed UTC adjustment from the local time and then add 1 hour. So, 02:00 - >>> (-05:00) - 01:00 = 06:00 UTC. >>> But, what if the local time is 01:59? One would subtract the signed UTC >>> adjustment from the local time and then??? So, 01:59 - (-05:00) = 06:59, >>> but what about Daylight Savings Time? The current local time being adjusted >>> is not with the DST range, but the adjusted time via the UTC adjustment >>> value is. Does DST come into play here? Is the decision based on the local >>> time or the resulting UTC time? >>> >>> A similar question comes into play on the other end of the DST range. If >>> the local time is prior to the end of the DST range, does one subtract 1 >>> hour from the adjusted time? >>> >>> Finally, what about the other direction. If one has a UTC time value, what >>> are the rules governing the change to a local time with respect to DST? >>> >>> I hope my explanation isn't too simplistic. Any thoughts or direction >>> might have that would help would be greatly appreciated. That also goes to >>> anyone else that might have some input. >>> >>> Thanks, >>> Chuck >>> >>> Charles (Chuck) Hardee >>> Senior Systems Engineer/Database Administration >> >> Have you looked at the IANA TimeZone Database? >> http://www.iana.org/time-zones Wikipedia entry: >> http://en.wikipedia.org/wiki/Tz_database >> >> That page has a compressed "text" file which contains a lot of TimeZone >> information. It is public domain. It is what GNU/Linux uses to adjust the >> local time from the UTC values. It has a _lot_ of data in it. It contains >> offsets for time zones and dates within that time zone (i.e. such as when >> the U.S. decided to change when to change to/from DST). >> >> Some Perl code at: >> http://search.cpan.org/dist/Date-Manip/lib/Date/Manip/TZdata.pod >> >> Unfortunately, I don't have any example code sitting around. Nor did I find >> any with a simple Google search. >> >> ... As others have noted there is no concept of Daylight time with UCT, which is not seasonally adjusted, only with local time zones. In the Eastern zone example given, to convert to UCT, if the local Eastern time is EST an offset of -05:00 is applied, or if local time is EDT an offset of -04:00 is applied. The adjustment and rules about when the adjustment is applied are only relevant for local time. The fact that England may observe daylight time in summer (British Summer Time), does not mean than UCT changes, only that their offset from UCT changes. If you need to convert UCT to Eastern time, you need to map the Eastern transition points implied by the rules into UCT date-time values: rather than try to apply Eastern zone rules directly to UCT values, you must convert the Eastern 0200 date-time-value at which transition occurs into a UCT date-time-value and compare against that to determine whether the target time should be EDT or EST.
An uncomfortable thought: If the vendor product in question is saving timestamps with inconsistent conventions, have you verified that it is indeed consistently using the correct offset to derive the UCT value from local time and the the change in offset values actually occurs at the proper local time? Our installation for decades has made the z/OS time transition concurrent with a Saturday night IPL in the 2345-0015 time frame, which though technically incorrect was a requirement imposed by application support, which was always more concerned about not running across the change rather than the precise time it occurred. Any product which depended on the Operating System to supply correct differentiation between standard and daylight time would be "challenged" for several hours twice a year on our system. Before spending too many resources on insuring that local-UCT conversions/comparisons are 100% accurate, I would first stop to consider whether an occasional inconsistency of one hour is truly significant in the context of how you plan to use these data-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
