At 08:03 -0500 on 06/07/2013, Paul Gilmartin wrote about Re: Age of
datasets in hours, not days?:
On Fri, 7 Jun 2013 07:29:09 -0500, 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.
Does STCK still guarantee unique readings, even subsequent to the advent
of STCKE?
24 hours of binary mircoseconds isn't very human readable either.
And still using local time leaves wide open the hour of uncertainty every
fall. It makes no sense to provide microsecond resolution while tolerating
that hour of uncertainty. Were the designers even thinking?
I agree. Once a year you have a 23 hour day with a 1 hour gap between
01:59:59 and 03:00:00 [one second later) and a 25 hour day (with the
sequence 02:59:59 being 02:00:00 one second later with the second
02:59:00 being one second before 03:00:00). Just going GMT is
simpler. So long as you store your time as HH:MM:SS, you can set MM
to 60-B9 for the second 2AM hour. For the lost hour, number the hours
00,01,25,26, etc. Any hour over 24 is 22 shown as 22 more than the
actual hour number (24 is reserved for 24:00:00 which is the midnight
of the prior day with 00:00:00 being midnight of the indicated day).
Then there is the 61 second minute (with the second before midnight
of the next day being 23:59:60) when there is a leap second.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
