On Tue, 17 Sep 2013 17:28:44 -0400, Charles Mills wrote:
>
>*Most* time fields are built by the individual record cutting product. If a
>product wants to record time as Latvian Summer Time expressed in Roman
>numerals in its SMF records it is free to do so. Thus one cannot say "SMF time
>fields are thus and such" (unfortunately).
>
I'm shocked and dismayed. You mean that SMF (whatever that is)
doesn't prefix a standard header to the information supplied by the
"record cutting product"!?
>Hmmm. I see the discussion of TAI and UTC in P[ro]Op but not sure I fully
>grasp what it all means relative to the actual setting of the system clock.
>The clock is set from the HMC on Power On, is that right? I don't have those
>manuals, at least not in front of me. What do the relevant manuals say and/or
>recommend?
>
Damn! I'm starting to miss Bookie. Is there any way to link (URL) to a
particular table in the P[ro]Op other than instructing the reader to
download the thing and citing a section number?
start with:
http://what-if.xkcd.com/26/
The guy knows his stuff. Really. Which links to:
http://tycho.usno.navy.mil/systime.html
>... UTC-ish time ...
>
YA time convention definition. I suppose it's as good as any.
My surmise (conjecture) is that prior to the advent of UTC in 1972
the TOD was assumed to run on GMT. But GMT varied, unpredictably,
but measurably from atomic time references, by less than one part
in 10**7. This is certainly good enough for IT, but not for some
scientific purposes (GPS, nowadays, e.g.).
So UTC was invented, in 1972, to run at the TAI frequency, but with
one-second offsets introduced sporadically to keep UTC within 0.9
seconds of UT1 (Earth Rotation, or GMT-ish time). At the introduction
of UTC in 1972, GMT (UT1, whatever) was 10 seconds behind TAI. IBM
elected then to respecify (needlessly, IMO) the TOD to run at the TAI
rate, but rather than introducing a 10-second discontinuity (in the bad
direction), 10 seconds behind TAI (perhaps better expressed as that
now the TOD zero epoch is TAI 1900-01-01t00:00:10)
So, prior to 1972, a simple congruential/affine computation sufficed
to convert STCK results to GMT. STCKCONV does (I assume; IBM won't
document it) correctly convert TOD to GMT in that era. Since 1972
(the only year so far with two leap seconds) STCKCONV (I assume)
returns TAI-10 seconds -- a useless convention, but IBM didn't care
to make it right.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
