[LEAPSECS] Lets get REAL about time.

[Keith Winstein]

On Sat, Jan 21, 2012 at 7:09 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> In message <CAMzhQmM18E8ssh3PRT+Jz3_hvraPiEWyxt4Yti47LFCUjxnBsw at mail.gmail.com>

> , Keith Winstein writes:

>

>>You are saying that if the time given is more than six months in the

>>future, realtime_tm() will simply return an error and will not be able

>>to produce a human-readable timestamp (whether in UTC, EST, EDT, CET,

>>BST, etc.).

>

> Correct, if we don't have the knowledge to do it, we fail the conversion.



>>Isn't this a problem?

>

> If it is, it's a not problem with the API, but with the way

> leap-seconds are defined.


Hmm, in practice I think the plan to simply fail with an error is
going to be a non-starter. Plenty of applications need to record dates
more than six months in the future; e.g. in a calendar program, the
user will want to schedule a meeting for August 1, 2012, from 9 a.m.
EDT to 10 a.m. EDT. The program will want to do all the normal things
-- calculate the duration of the meeting, how far in the future it is
(so it can put it in sorted order along with the other events of that
day), etc. In a subscription service, we might want to say that the
user's subscription lasts until January 22, 2013 at 12:21 p.m. (one
year hence) and give them a countdown (264 days remaining) as that
timestamp approaches.

Perhaps you envision a whole other, separate API for representing and
validating EDT (and other civil time, and UTC) timestamps and doing
approximate arithmetic on them until the happy moment when they can
finally be successfully converted into a realtime_t, but if so this
introduces considerable extra complexity and will need to be
specified. People are going to want to evaluate the whole package of
what they're getting into before they sign on to this thing.

The notion that "the API" can do nothing more than report an error
message is not quite right. There are some alternatives:

1) Ignore leap seconds when converting future EST/EDT/UTC-specified
moments into a timestamp.

==> This is the current POSIX status quo, and it works pretty well for
the vast majority of applications.

2) Correctly account for past leap seconds, and ignore
yet-to-be-disseminated future leap seconds when converting
EST/EDT/UTC-specified moments into a timestamp.

==> This is the current status quo using the "right" timezone files.

3) Correctly account for past leap seconds, and bomb out with an error
when converting future EST/EDT/UTC-specified moments.

==> This is your proposal.

4) In addition to the "double *error" returned by tai_time(), also
report an error estimate from the conversion routines realtime_tm()
and tm_realtime(), reflecting the uncertainty from the fact that
future leap seconds may not be known far enough in advance. The
conversion to and from UTC is uncertain, but not totally unknowable.
Calendar applications might be perfectly happy with a +/- 10 second
error on a timestamp years in the future.

5) Instead of a quantitative estimate from #4, you could simply return
a boolean reflecting whether the conversion is exact or might be some
seconds off because of as-yet-unannounced leap seconds.

That is, instead of "bomb out and return an error" for future
timestamps, the API can "do the best conversion possible and return a
warning if necessary."

===

On balance, I think #5 may be the best compromise between usability
and correctness. And it is much more likely to be accepted than an API
that rigidly bombs out for timestamps in the future, just because the
conversion may be off by 1 second. Most applications do not need this
level of accuracy for future timestamps but still want a conversion.

-Keith