I'm going to tak a contrarian view -- at least from the perspective of the group here -- and assert that the Posix committee got it nearly right. (Or at least that the damage was done before the standardisation effort got under way.) Posix time, unfortunately, has served a dual purpose. It is used for measuring intervals - but it is also civil time: "what time is it on the clock on the wall?" And it has been used - from the very earliest days - as a calculation device for the civil clock. I would venture the guess that virtually all programs that depend on "seconds from 1 January 1970" actually are doing things like computing days between two times:" (time1/86400 - time2/86400). Programmers who do things ranging from financial applications to television schedules want this convenience. Eventually, those who do television schedules realize that they have to deal also with leap seconds and drop frames. But that sort of thing winds up being left to specialists: the people who code the business applications of television don't care about those details, don't want to care, and shouldn't have to care. Even the technical directors and videotape editors are usually ignorant of the details: "some seconds have only 29 frames. It's like leap year" is the usual level of understanding. And having an integer representation of civil time, that well-defined calendar algorithms can handle without auxiliary tables that need to be updated, is too great a convenience to pass up lightly. So: Make the TAI clock separate from the UTC clock. Synchronize the two, either using something like adjtimex() that makes the change almost imperceptible, or by making the change rare enough that it can be a planned-for event (the 'leap hour' proposal). I don't really care which. (The code that I've written does the first, because that's the best compromise available with today's standards.) But don't take away an integer "UTC clock" merely because it ticks irregularly. The irregular ticks are useful for the vast majority of people to whom leap seconds are an academic curiosity. Define a new set of APIs for dealing with TAI. If that's too much work, bite the bullet and accept leap hours. We won't need one in the lifetime of the prospective lifetime of the great-grandchildren of those in the cradle today. That may be kicking the can down the road, but it's a very long kick. -- 73 de ke9tv/2, Kevin