On 28 January 2011 20:42, Tom Van Baak <t...@leapsecond.com> wrote: >> As I said before, having looked at the subject, I now strongly believe >> that any alteration to the current scheme of occasional leap-seconds >> would be a serious mistake with large consequences. > > Can you explain the above comment a little more?
Viewed from afar, leap seconds appear to be a really stupid idea. A gross complication in the passage of time, that so few people care about, yet can cause such nasty effects such as time going backwards. Based on 10 years experience of Joda-Time, I can see what API users understand and what they don't. Variable length months (June 30, July 31) are well understood, yet occasionally cause problems. Leap days are understood, yet users often forget them or complain when they occur. Time-zones are frequently forgotten, and many don't understand them or why 01:30 doesn't exist. Leap seconds are just not even considered. Asking users of dates and times to cope with variable length months, leap days and time-zones is more complexity than many can currently handle. Expecting them to understand about leap seconds is a step too far. (Try asking your business analyst what the software should do on a leap-day and they'll tell you, they can probably tell you what to do at a time-zone change if they think hard, but they'll never know how to handle a leap second) But... The Earth does not rotate at 86400 SI seconds per day. Once I internalised that fact properly, my requirements were clear. For the main API days must have 86400 "seconds" (not necessarily SI) and days were more important than seconds. I came to the conclusion that I, as I believe my users do, care far more about days formed of 24 hours, 60 minutes and 60 "seconds" far more than any leap second notion. Thus, no matter what, the Sun must peak at midday and it be night at midnight, with adjustments to ensure that based on time-zones. Since stopping leap seconds breaks that basic principle, it became unacceptable. Moerover, amongst experts, leap seconds are well understood. Removing them, or changing the scheme in some way, simply causes yet another form of historical anomaly in the time-line to deal with when considering the past. That anomaly would be worse than any "cure". Plus, GPS, time-signals, and OSs all have some form of dealing with leap seconds at his point. The cost to change is far too high. Beyond that, implementing leap seconds turned out to not be that hard. You simply separate into three - TAI - simple incrementing number that is well-defined (although clearly not everyone here will agree with that). TAI can be used into the far future and the far past - UTC - the current world standard with leap seconds (picked up from the zoneinfo data). UTC cannot be used especially safely for the future. - 86400 - what everyone really wants Given that, I needed a way for time to always move forwards, and to resolve UTC to 86400. Solution UTC-SLS. Thus my conversion is based around the primary importance of the day, and its subdivisions of hour, minute and second making a fixed 86400 pattern. Leap seconds provide an easy to understand way to cope with the detailed scientific requirement that is easy enough to manage if dealt with separately with a simple clear mapping like UTC-SLS. In other words, once I had fully understood leap seconds and the variation of the Earth's day, leap seconds were an obvious solution to the Earth problem and UTC-SLS was an obvious solution to the human problem. The two go hand in hand. The only other approach that makes sense to me is to define the human-second as 1/86400th of a day, and rename to SI second to the tic or some other name (its easier to get scientists to rename their units than the general public). But in my view, the mapping between the tic and the human-second is harder with this approach than using leap seconds and UTC-SLS. Thus, I believe there is more chance of getting the computing industry to adopt leap seconds than anything new, especially with a simple conversion like UTC-SLS which is quite frankly ideal. BTW, I have a physics degree, so come from a science background, although I remember very little of it. These days my primary concern is working out what "the masses" need and designing APIs that they can successfully use easily and without error. Stephen _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs