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
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
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
More information about the tz