Chuck, I think you are approaching the need for conversions a bit too generally. For your historical data, I presume you know (a priori) the time zone value for each set of data.
The only conversion you need to do is local to UTC (or UCT as some have named it; I prefer to use UTC myself). Use the tzdata tables already referred to you to select the proper conversion value based on your a priori knowledge of the time zone. Once you have converted local to UTC, no further conversion is needed. No further adjustments are needed, you have a unique time value. Using your US East Coast example, when you have an input local time of 01:59:59.999999 on the day of the switch to DST you convert that time to UTC and you have a value of 06:59.59.999999. In the next record you process, the local time you see in the input data is now 03:00:00.000000, but since this time falls after the conversion time of 02:00:00.000000, you now use the DST offset to convert to UTC and your resulting UTC value will be 07:00:00.000000, one microsecond after the pre-DST time. No other adjustments are needed to the output UTC times, they are unique. Do all of your matching in UTC time values, never in local time. Now, if you desire (or management desires) to convert the matched time values back to local for display in your output file(s), once again you know the time zone for each set of data so you can perform the conversion. Here however is where the output might be confusing to a reader of that output, because at the fall conversion back to "standard" time there will be duplicate local time values for an hour, even though the UTC values are unique. Try to convince whoever wants to see local output time displayed to accept the UTC value instead, or at a minimum two columns, UTC first and local second, so that the unique time is apparent. Again in the US East Coast example from above, when converting back from UTC to local, you would compare the UTC time to 07:00:00.000000. If earlier then use the non-DST conversion value, if after then use the DST conversion value. You can, of course, parameterize the boundary time values (02:00:00.000000 and 07:00:00.000000 in the US East Coast example) in a program to use values derived from the tzdata tables instead of hard-coded values, and obviously this is a recommended approach for a general solution. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hardee, Chuck Sent: Saturday, June 28, 2014 2:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local Time conversion to/from UTC Time 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
