Mark H Weaver wrote: >You seem to be assuming that SRFI-19 durations should _always_ represent >intervals of TAI time.
No, that is not my position. Although SRFI-19 isn't entirely explicit on this point, it is in the nature of the problem space that a duration may be measured on any time scale, and it seems to be implied that time-difference will determine the duration on the time scale of its inputs. Indeed, if the duration were always to be determined on one specific scale then it would not be necessary for time-difference to require its two inputs to be of the same time type. With respect to UTC, my position is that time-difference on inputs of type time-utc should determine the duration as measured in UTC seconds. For times since 1972 this is always the same as the duration in TAI seconds (elaborated further below). For 1961 to 1971 UTC durations and TAI durations differ, and that's the subject of my bug#26632. Note that in that bug report I explicitly converted time-utc->time-tai where I wanted to determine a TAI duration. > every UTC day has >exactly 86400 UTC seconds, No, that's not how UTC works. There are some time scales derived from UTC that have exactly 86400 seconds for each UTC day, such as Markus Kuhn's UTC-SLS, or that have exactly 86400 seconds per UTC day in the long run, such as Google's "leap smear". But SRFI-19 doesn't refer to any of those, it refers to UTC. The true UTC has a variable number of seconds per day *as judged by UTC clocks*: the days are not merely different lengths as judged by TAI. The variable number of UTC seconds per day is the source of the famous "23:59:60" notation. On a day with a positive leap second, the first second of the day is centred on 00:00:00.5, the 86400th second is centred on 23:59:59.5, and the 86401st second is centred on 23:59:60.5. These are 86401 distinct seconds counted by UTC, each with a distinct label. On a day with a negative leap second, UTC only counts 86399 seconds: the time-of-day labels never reach 23:59:59. It is intrinsic to the definition of UTC that durations (measured in seconds) don't match up regularly with time of day. It's just like the way that intervals measured in days don't match up regularly with day of month: the way to think about a day of UTC is a lot like the way one thinks about a month of the Gregorian calendar. (Though there's an important difference in that we know the lengths of Gregorian months arbitrarily far in advance but only know UTC day lengths months in advance.) Wanting to avoid all that irregularity is the motivation to use UTC-SLS and the like. >Having said all of this, I should admit that I'm not an expert on time >standards, I am. Incidentally, there's an aspect of the present bug report that's different in the pre-1972 era. time-difference correctly shows a duration of exactly 86400 seconds on the UTC scale for an ordinary day in that era, such as 1967-03-14 of which I examined the TAI duration in bug#26632. But it incorrectly shows the same duration for a day with a leap. That's the same error that it makes for post-1972 leaps, but there's a difference in that the duration of the leap (as judged in UTC) is non-integral, being derived from a non-integral number of TAI seconds and also affected by the frequency offset. For example, the UTC duration of 1968-01-31 (also examined in bug#26632) was exactly 8639990259200/100000003 seconds (roughly 86399.900000003 s). This runs into trouble with SRFI-19's insistence that the nanosecond field of a time object only contain an integer. -zefram
