On Mon 2006/01/09 10:01:27 -0000, "Clive D.W. Feather" wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
I've just read through the email that has accumulated on this list since before xmas - impressive volume! Why not devote a fraction of that time and energy to producing a formal position paper. >You've expressed it very badly in the article. ...and you've expressed this rather tactlessly! >The problem is not that UTC >can't be expressed as a real number. Rather (and you do sort of say this, >just not very well), the function UTC(TAI) is not continuous and monotonic. I can't let this one pass - UTC is continuous and monotonic. In fact, ignoring differences in origin, UTC = TAI. Surprised? If so then you're confusing a quantity with its representation (though in good company in doing so). First consider a graph of a person's age versus calendar date with a precision of 1 day. The fields in calendar dates are mixed-radix, the day field is also variable-radix depending on the month, and for February the year, so how should we plot the calendar axis? Simple, do it as a count of days and then label it with year, month and day-of- month; Feb/29 in leap years comes out in the wash. As expected, the graph is a continuous straight line of slope 1 - no breaks, no kinks - the person doesn't age in fits and starts! Now consider extending this graph to sub-second precision, accounting for leap seconds, with age to be measured in TAI and calendar date in UTC. Now the date axis must be constructed as a count of seconds of UTC (SI seconds, same as TAI) measured from birth. As before label the date axis using conventional calendar/clock notation. The graph is still a continuous straight line of slope 1 (no breaks, no kinks). Leap seconds are labelled as 23:59:60 - that is the formal representation, each second of UTC has a unique label as required for mathematical validity. (Note that it is incorrect to repeat the seconds count at 59, 00, 01 or anywhere else, even though that may be required on clock displays for practical reasons.) Doing arithmetic on UTC using clock notation is like doing arithemetic on calendar dates or with numbers using Roman numerals. The principle difference is that leap days follow a set rule and computations involving future times can be performed, whereas leap seconds do not follow a set rule and computations cannot be performed into the future. I am reminded of a discussion concerning the curious repetition of "1828" in e = 2.718281828... Simply reexpress the number in base 2, base e, or something else; the pattern disappears. Mark Calabretta ATNF
