[art] summary of updates - draft-time-touch

[Joe Touch <[e-mail]>]

Hi, all,

So I have a set of things to update so far. Please let me know if I
missed something. I will have an update out by the end of this week.

I'm hoping this update can help us converge...

Joe
---------

- clarify TAI as a post-facto average
- clarify prev definition of astronomical second as instantaneous:

1/31556925.9747 of the tropical year as of the instant
1900 January 0 at 12:00:00 Ephemeris Time.

- clarify UT1 as a a measure of the orientation angle of the earth upon
which international agreement bases the notion of calendar days.
- consider cleaning up the UT definitions, noting mostly that UT1 is the
only one in use (and not getting into the detail of UT0 and UT2)
- clean up the POSIX definition (it's not solar; more like a local clock)
- this is all at mean sea level (we're ignoring relativistic effects)
- reminder that the POSIX "equation" is approximate
- a light discussion about implementation issues (e.g., struct timeval
vs struct tm vs. ISO 8601)
- fix NTP epoch to 1900-01-01
- clarify the two solar times as "apparent" vs "mean"
- reminder that timers either end on a date or specify an interval
- reminder that future times in UTC are indeterminate
- UTC is known only into some future (e.g., a few months) that you know
about scheduled leaps
- earth rotation, not orbit, causes most of solar time variation

One other thing that came up is the difference between "POSIX time"
(previously called Unix time) and the POSIX time API. The API can access
a variety of time scales, including UTC (e.g., when NTP is running), an
emulation of UTC, an emulation of Unix time, or direct access to a
monotonic counter (which may or may not be reset on reboot). I think
this is Nico's issue with data types, and it's worth clarifying.

-----