> From: Greg Troxel <[EMAIL PROTECTED]> > > It seems very odd for time-utc->date to pay attention to leap seconds. > I would only expect leap seconds to come into play when converting > between UTC and TAI.
Procedure time-utc->date resents the anthropomorphism. The author of that procedure probably paid some attention, but not enough, otherwise the answer would be right. > The whole point of UTC is to have a timescale with the same number > of seconds per day so that one can ignore the mess of leap seconds. I think this is provably false. If anyone wants to argue, I will look up original references, but for now I will just quote something I wrote a few years ago, after spending much more time on this issue than all the leap seconds in the history of the universe. > UTC can not be expressed as a single number (in any units), but must > be expressed as a day (either Julian Day or Gregorian Calendar > Date), together with a time within that day (expressed as hours, > minutes, and seconds, as total number of seconds, or as a fraction > of a day). This is because the days are not all the same length. > Most of them are $86\,400$ seconds (exactly), but when a leap second > is inserted the day is $86\,401$ seconds (exactly). > With UTC, one represents seconds since the epoch in a way which does > not count leap seconds. UTC is _not_ expressed in seconds. If it were, it would be messed up whenever a second passed without incrementing the count. > With TAI, the count includes all seconds > (TAI-UTC currently being 33) This true (to within a second) and explains why we don't use TIA much. It's too hard to figure out the date, which the boss cares about. > (I would say that a time difference of two UTC times should return > the arithmetic difference of the two seconds-since-epoch values, and > of two TAI times the same thing, but the TAI ones will have leap > seconds. This is not clear in the srfi-19 text.) The srfi says the input to time-utc->date is a of type time-utc. I don't find a definition of that in the srfi. (There is a symbol with that name, but no type.) It probably means a time object with component time-type set to the symbol time-utc. This is bad, because a time object is a count of seconds, and UTC is not. > So, I'd say time-utc->date doing any leap second lookups is a bug. I don't know what a procedure should do if it is based upon a spec that violates international standards. > > Ondrej Zajicek <[EMAIL PROTECTED]> writes: > > > >> (date->str (time-utc->date (date->time-utc (str->date "01-01-2006")))) > >> -> "31-12-2005" > >> > >> Is is a bug in leap second handling or is it a expected behavior? I am open to argument on other things, but I am sure that if this is expected behavior, it is bug in someone's expectations. -- Keith
