[LEAPSECS] Lets get REAL about time.

[Mark Calabretta]

On Mon 2012/01/23 08:05:15 -0000, "Poul-Henning Kamp" wrote
in a message to: Mark Calabretta <mcalabre at atnf.csiro.au>
and copied to: Leap Second Discussion List <leapsecs at leapsecond.com>,
      "Keith Winstein" <keithw at mit.edu>


>>So effectively what is needed is a function to subtract two tm structs.

>

>You can always compare them ("is date1 before, the same or after date2")


OK.


>but you cannot subtract them and get a precise time-difference, if they

>span a potential leap-second application.


Not an exact time difference, but you can get one to a level of accuracy
that is more than adequate for all but the most stringent purposes.
This is already the case when subtracting two time_t values converted
from tm structs, whether past or future, because mktime() can't account
for leap seconds.  However, if one of the times is "now", then the
result becomes more accurate as the difference gets smaller.  That's the
important property for triggering an event.


>But a similar problem appears as soon as we try to compare or subtract

>two timestamps in two different civil timescales, which includes

>UTC in my design:  Som looney politician might change the timezone

>before we get there.


I agree with not allowing users to perform undefined conversions to/from
realtime_t.  So when converting between it and UTC, the API returns EDOM
(E2BIG) for conversions beyond the leap second table.  No argument there.


>>Currently this is done by the user by converting the two structs to

>>time_t and subtracting those.  The implicit assumption is that that

>>would now be done via realtime_t.

>

>No, that will fail if we don't have a leapsecond table valid for

>both timestamps.


Correct.  So something must be provided to replace the implicit
assumption that it would be done via realtime_t (assuming that time_t
goes away).

In a nutshell, the problem is to allow future dates to be stored AND to
provide a simple means of computing the approximate timespan till that
date occurs.  So far we agree that the date can only be stored in a tm
struct, and that in general it won't be possible to convert it to
realtime_t for computing the timespan.

I offered the solution of providing a function to subtract two tm
structs.  It would be included with the realtime_t suite of routines
even though it doesn't deal with realtime_t values.  This is how the
man page might start:

  int tmdiff(const struct tm *tm1, const struct tm *tm2, double *diff);

  Return the time interval, *tm2 - *tm1, in SI seconds.  An approximate
  result may be returned where one or both represent a future time.
  When differencing UTCs more than 175 days in the future, a worst case
  error of one second in 175 days (1 part in 15e6) may arise from future
  unannounced leap seconds.  When differencing particular time zones, an
  error of one or possibly two hours may arise over short periods due to
  late announcements of changes in daylight saving time.

As I said, these uncertainties are already inherent in differencing two
time_t values converted from future-valued tm structs, yet life still
goes on.

Regards, Mark