On 6/7/2013 5:29 AM, John McKown wrote:
IMO, if IBM were to store the creation date & time, then the only logical value to store is the STCKE value taken somewhere within the allocation process. It is 16 bytes in length and cannot be made any more accurate because the hardware doesn't support a greater accuracy. It is not human readable, but SO WHAT? It is easy to convert using HLASM and the STCKCONV macro. I wish that the LE people had an STCKE value to Lilian date/time conversion routine. But, again, that would be easy to write in HLASM.
As a software developer, I have had multiple occasions to process event times stored as all or part of a TOD value. For obvious reasons, end users prefer everything displayed to them in local time. Therefore, accurate reporting of these events in human-readable form requires knowledge of the locale's time zone policy going back many years (for (E)JES, we go back 10 years). For this reason, I have come to very much appreciate event times stored as local time. For example, ISPF stores member create/update time as a local time value. No conversion necessary.
Of course, for 100% coverage of all possible usage scenarios, time stamps should contain both UTC and local time.
-- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
