the ``need'' for POSIX times

[Antoine Leca]

D. J. Bernstein wrote:
> 
> Antoine Leca writes:
> > OTOH, your API impedes the use Markus is speaking about
> > (discarding leap seconds), and that is a nuisance sometimes.
> 
> Oh, really? Show us some programs where you claim it's a nuisance.

My usual use for the date and time functions in the C library
is to calculate a date that is X u apart from a given point,
where "X" is a number and "u" some unit of time.
The most usual is: in 1 month, but a very common one is:
in 1 week.

The first computation requires the use of mktime normalisation.
But the second does not (if I start with a time_t value),
because, *in the absence of leap seconds*, I just need to
add 7*86400L to my start value.

I do not claim this is the most used function of the library,
because it certainly isn't.  But since you asked for an
example, I give you the best I can find.

Also, don't argue with me that your library allow it.
I perfectly know it.  My point is that it is not *that* easy.

 
> > (Many people are *very* comfortable with the fact that
> > a day is 86400 seconds, not a pseudo-random value...)
> 
> That isn't a fact; it's a fantasy. A UTC day is _not_ guaranteed to be
> 86400 seconds. If your code doesn't work correctly during leap seconds
> then it's wrong.

Good point, but I won't argue with that.
I, and most users as well, do not care what precise value an
UTC day, or hour, or second, is.
They (and I) want reliable and mostly straightforward ways to
resolve *their* problems, not trying to write convolutate
programs to handle the fantasy of Earth movement.

 
> libtai makes it easy to do the right thing.

For the knowledgable people, yes, and everybody seems to agree
with you here.
My point is that it *requires* some users to "do the right thing"
for the most simple tasks, even if their tasks have no real link
to the bare reality of UTC time scale.

BTW, what is your objective? do you think we should take
your library and pasting it in the C standard?

 
> > effectively, this means either *every*
> > hosts should have an uptodate leapsecodns table, which
> > is unrealistic,
> 
> Repeating that assertion doesn't make it true.

What is wrong? The need for the table (which you are speaking
about just after)? or the fact that its distribution is
unrealistic?

If it is the realism, let's give you an example: I am in charge
of the maintenance of thousands of machines running Windows 95.
When W95 appears on the market, it carries a wrong table
for *our* time zone (change at midnight locale time, the last
sunday of september!).  We are in 1998, 60 months away from the
needed change in the table; nevertheless, we had quite a number
of users who shifted two weeks ago... because their tables have
not been updated.
I agree with you the updating of the leapsecond table is much
more critical, so cannot suffer from a delay that big.  But
since the difference is only seconds, I am quite sure *most*
of my users won't be up to date at a given point of time.

Again, there is a difference between a knowledgable person,
like you are, and Jean Utilisateur-Moyen.

Also, I do not want a C standard that requires every host
to run NTP or a equivalent protocol...


> The cost of distributing up-to-date leap-second tables
> is minor---certainly much less than the costs imposed
> on future programmers by Markus's API.

At least in my part, the cost of distributing any
patch is much heavier than any burden imponed to any
programmer, how severe it is (that is a little too
strong, but you should get the idea).
The very point is that my fellow programmers (and
I as well) do not accept this reality, and certainly
won't change their habits, so don't do it.
But it does not change the fact.

Also, where do you find overwhelming costs behind the
adoption of Markus's proposal?  I am not Markus, I do
not want to promote its work particularly.  But I also
see only a very limited part of the picture, so I will
like to know where are the problems of each solution
to try to forge a better one.
If we spend our time critizing, nothing will happen.


Antoine