[LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Steffen Nurpmeso]

Warner Losh <imp at bsdimp.com> wrote:
 |If there was an easy solution, it would have emerged by now. Trouble
 ...
 |support for spending boatloads of money to fix it. The problem is that
 |you never know if the following code has a leap second issue or not.
 |Let's suppose for a minute we redefined time_t to be TAI. Let's
 ...
 |time_t foo;
 |foo = get_some_time();
 |foo += 60;
 |do_something_at(foo);
 |
 |Does this code say "do something in 60 seconds" so it will slip 1
 |second within the minute over a leap second. Or does it say "Do

With localtime you do have exactly the same kind of problems, and
only thanks to the TZ project it has become possible for small and
very small companies to deal with that somewhat correctly.
Of course you can compute with UTC and only convert final, user
visible values, but, e.g., calendar printouts of future dates
might turn out wrong.
It might not in Europe or the U.S., but that seems to turn things
to be boooring for many people.  (There is this i think Japanese
man who has this lifelong goal of never doing a day the same as
the other one, but how many humans have this strength?)

 |something one minute hence at the same offset within the minute?" For
 |the casual observer, those two statements are the same. but to the
 |computer, they are different. And it isn't something that's easily
 ...

Never having done kernel programming, this doesn't sound logical
to me.  You have a clock source and a conversion algorithm.  That
runs every time, maybe even millions time a second?  Maybe kernels
exist which don't do any work unless there is real work to be
done, due to I/O or application requests etc., then synchronizing
on soft startup only, a.k.a. less often.
It appears to me that it would be a single additional subtraction
to get to UTC, would that time signal be tracked as TAI.

 |One could imagine having a more complicated structure that could cope
 |with the inherent ambiguity in future times. I can't say "schedule an

So there is no ambiguity for CLOCK_TAI.

The ambiguity for UTC is to adjust time for our home planet, or
what remains of it now that we listen to some middle-age eight
cylindre blues that is to say -- e.g., ~58 percent loss of species
in a fourtyfive years study from i think WWF it was?
Yes, yes, i know about that great future with those Big Macs that
have grown in the genetical laboratories etc., and the cloned-back-
to-life green plants everywhere (take for example that fantastic
invention of the "CityTree", how fine that is).
Until then i realize -- i very _much_ realize when i look out of
my window, to say the truth -- that the sun and the light and
warmth it brings is a very crucial aspect of not only my
subconsciousness, and i now start looking forward impressable to
the leap second that is to occur to bring us in sync again.  Yes.

 |event exactly 1 year from now" for example without it. I need
 |additional metadata around to know if I want it to happen at the same
 |time of day on the same date or if I want it to happen after than many
 |seconds have elapsed. You can't convert a putative UTC time to TAI
 |time until you are within 6 months of that time (the current
 ...

Yeah, sorry, but that is what it is.  Those financial warriors
need it for timestamps, with subsecond precision.

 |As an aside, UTC could be made more predictable if a schedule was
 |announced like we do leap days. We can be off by several days because
 ...

But what is the application you need this for?
You want to know future dates with subsecond precision --
Armageddon won't happen, thanks to Bruce Willis -- but never cared
for correct date handling of the past.  No one ever did.
One day you will turn around and find nothing but scorched earth
behind your back.

 |Having said all that, I totally get why people want UTC to have leap
 |seconds. I get what that enables. I'm suggesting, though, since
 |software is running life more and more, we'll see stop-gap solutions
 |like the smear paper over things until the stop-gaps get too much of a
 |hassle to do and there's a growing call to harmonize the two world
 |views in favor of POSIX. We aren't there yet, I'll freely admit. But
 |the last 16 years I've been involved in the problem, there's been
 |little movement to a real solution to the mismatch and I'm pessimistic
 |that the hard line of UTC can be maintained forever.

We agree in pessimism.
What else after such a year.  On the other hand, history repeats
itself.  Even the Red Baron von Richthofen writes "In 1916 at
latest it was no longer fun" (badly translated).  And then there
was the summer of love, and Kate Bush even thereafter.
My my, hey hey.

--steffen