No subject

Wed Jul 13 23:14:41 UTC 2011

the devices that you're talking about.

   >     Second, implementation X can't convert timestamps outside its
   >     window to internal format, so it will reject attempts to invoke
   >     primitives involving TIME_UTC timestamps outside its window, as
   >     the internal format of those timestamps would be undefined.

   Please tell me exactly which operations in my API you think would fail.

All operations that take out-of-window struct xtime values would fail,
because implementation X converts struct xtime to its internal format
(TAI within a window) in order to do all operations.  This is a
reasonable implementation.

   Remember that only tz_jump and xtime_conv depend on the leap second
   history, all other functions do not care about the leap second history

This is true of the implementation that you're thinking of, but I
don't think the C standard should require such an implementation; it
should also allow implementations that are fundamentally TAI based as
described above.

   if you know only all leap seconds since you inserted the batteries and
   TIME_MONOTONIC started, then xtime_conv will not allow you to convert a
   TIME_UTC value from before you inserted the batteries to a negative
   TIME_MONOTONIC value. But why would you want to do this, since you never
   received a corresponding clock value from the clock anyway?

Because you imported a leap-second timestamp from some other source,
e.g. from a correspondent over the network using the draft IETF calendar spec.

   > 3.  The struct xtime spec does not support applications that do not
   >     want to know about leap seconds and do not ever want to see them...

   First of all, the existing POSIX functions as well as BSD's gettimeofday
   are continuing to exist.

Not all applications run on POSIX or BSD.  And it's messy and
error-prone for implementations to combine BSD gettimeofday or
POSIX.1-1996 clock_gettime with struct xtime.  We should give people a
simple way to do common things.

   You can always call xtime_delay yourself if you are inside a leap
   second and call xtime_get again afterwards.

This is the sort of hack that most users are unlikely to think of on
their own -- and also it will impose unacceptable delays on some apps.
We need a simple way to get the desired values, without delays.

   If you want to get a special filter (e.g., the US 59 Hz power grid
   leap rule or the BSD 10000 ppm adjtimex() rule), then you can
   implement easily this specific rule using tz_jump (just do: if the
   last leap second is less than 60 s away, add a linear compensation
   ramp (delta_t / 60.0) to the time).

I thought that tz_jump was supposed to report only discontinuities.
Aren't these filters continuous?

Now that you mention it, though, it'd be nice if tz_jump (or some new
primitive) also reported continuous changes to the TIME_TAI and
TIME_UTC clocks as well, if that information is available.  This is a
good idea, and will better support apps that don't want to know about
leap seconds.  It is a reasonable extension, though offhand I don't
think it needs to be in the standard.

   > If you combine solutions (2) and (3), then you don't need the current
   > TIME_UTC any more.  It's enough to have the generalization of TIME_TAI
   > with implementation-defined epoch, along with the variant of TIME_UTC
   > that never reports leap seconds.

   So I can't get the current UTC any more directly from the source?

Yes you can.  I'm assuming that the actual source is a TAI clock with
an unknown epoch, with a known relationship to UTC within a particular
window.  Within the window, one can say that ``the source'' is TAI or
UTC -- it doesn't really matter, and it's a mere notational
convenience to say one or the other.  Outside the window, you can't
convert clock values to broken-down UTC times no matter which
notational convention you use.

The differences between my proposal and yours are mostly ones of
notational convenience; they aren't fundamental to the implementation.
My basic argument is that it's much more convenient to base the clock
on an integer than to base it on a structure containing a
somewhat-broken-down time, with all its foibles.

   And all conversion functions suddenly depend on the leap second
   table and on the implementation defined epoch, including all the
   calculation overhead and reliability concerns involved with this?

The (partial) leap second table and implementation-defined epoch is
inherent to this sort of implementation.  You can't properly support
UTC leap seconds without it.  In this respect, the ``calculation
overhead'' and ``reliability concerns'' of integer-based clocks apply
with equal force to struct xtime.

   Do you really want to send every time stamp on its way from the external
   UTC reference to the output formatting routine several times through a
   leap second table

Going through a leap second table won't cost much, compared to all the
other things that need to be done to convert.  This is particularly
true for implementations that know at most one leap second -- that
table is pretty small.  :-)

If an app is really concerned about this miniscule overhead, it can
avoid the overhead entirely by using TIME_UTC timestamps instead of
TIME_TAI timestamps.

More information about the tz mailing list