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