There is nothing in error with any of the conversion services. They do what they intend to do. And yes they do the easy part. What there is is a lack of functionality that would usually be unimportant to have.
There is expected to be some human understanding of the foibles of a human-readable report. It should be unimportant to a human what the exact local time (accounting for leap seconds as well as local time zone offset) local time or even the exact UTC time (accounting for leap seconds) was. What could well be of importance is the relative values of the STCK(E) value for two things. This is why it is generally a bad idea to save local time, and even a bad idea to save UTC time, as opposed to saving the STCK(E) value. Sure, a service could be provided to convert a time stamp to one that subtracts out the value corresponding to the leap seconds at the particular time. That service would have to be updated every time a leap second is added which wouldn't be a big deal, but is work to do. Make a business case and ask for such a service. I believe that no one has. And that would only help for STCK(E) <--> UTC. Exactly when a time zone offset change occurred is unknowable in general, so trying to figure out the true local time based solely on a STCK(E) value cannot be done; additional data would be needed. As to this statement >z/OS shirks by shutting down user tasks during that second. "Shutting down user tasks" is not true in general that, but can be true depending on your time protocol. For the case where it is true, it should be apparent that no other approach could possibly work in order to accommodate dependencies upon timestamps to determine the sequence of events. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
