### Re: What problems do leap seconds *really* create?

grows quadratically; that is the problem. Mark Calabretta ATNF

### Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

be best to implement procedures to handle this conversion correctly from the start. Anyway, I agree with your basic point that system time be maintained in TAI. Mark Calabretta ATNF

### Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

difficulty in having systems use TAI internally and maintain a table of leap seconds for conversion to/from civil time? Mark Calabretta ATNF

### Re: Precise time over time

saleable with an initial timescale of, say, 20 years, extended by 5 years every 5 years. So at any time the extrapolation would range between 15 and 20 years. Mark Calabretta ATNF

### Re: Consensus rather than compromise

daylight saving switches. Inevitably it also means that the world's timezones would fragment as adjacent civil administrations adopted disparate policies on timezone adjustment. And then, as the political map of the world changes, so the record would become ever more hopelessly complicated. Mark

### Leap seconds BoF

, a few well chosen, specific examples that illustrate the technical aspects of your argument would be most effective. Mark Calabretta ATNF

### Re: Consensus rather than compromise

of a separate TZ rule table. How is it different from having to keep a total history of leapseconds ? The table of leapseconds is a function of time but not place. Mark Calabretta ATNF

### Re: Leap seconds BoF

behind the scenes and do it? Or must we try to represent your arguments for you? Mark Calabretta ATNF

### ABC leapsec article

The RAS statement seems to have generated quite a bit of media comment: http://abc.net.au/science/news/space/SpaceRepublish_1466849.htm Mark Calabretta ATNF

### Re: The real problem with leap seconds

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

### Re: The real problem with leap seconds

On Mon 2006/01/09 10:38:54 -, Peter Bunclark wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL I't be interesting to do an FFT on this list, and see if some of the contributers actually ever sleep, or do any other work... I had the same thought - the moreso when I reflect on the nil response

### Re: The real problem with leap seconds

no gaps, jumps or kinks. The only difference between UTC and TAI is one of representation, like the current year which may be represented as 2006 or MMVI but it's still the same year. Mark Calabretta ATNF

### Re: The real problem with leap seconds

, but that is not a necessary consequence of leap seconds. To their credit the CCIR did not stuff up in specifying the clock notation to be used for UTC. Mark Calabretta ATNF

### Re: Monsters from the id

, in terms similar to the above, what will happen when a leap hour is inserted? Mark Calabretta ATNF

### Re: The real problem with leap seconds

, TAI, UT1, or something else. In fact, in the situation where it's used the accuracy doesn't warrant it. Mark Calabretta ATNF

### Re: The real problem with leap seconds

. Is it also specified in TF.460? If so, how do they relate it to the notion of DTAI? In practice, refer to the example I gave on Jan/12. Mark Calabretta ATNF

### Re: The real problem with leap seconds

offsets from UTC, but only with minute resolution. I seem to remember that Clive Feather once proposed this for an extension to the C programming language. ... where UTC here is taken to be in the usual (fixed-radix) sexagesimal format. Mark Calabretta ATNF

### Re: Monsters from the id

, and that at least one of the timescales is genuinely discontinuous. Mark Calabretta ATNF

### Re: The real problem with leap seconds

of the continuous time axis has a unique UTC representation. Mark Calabretta ATNF

### Re: Monsters from the id

other than a political device? If so, please describe in detail how it could/would work. Mark Calabretta ATNF

### Re: The real problem with leap seconds

(of TAI) has two interpretions, one giving TAI (exact) and the other UT1 (approx), the latter being offset from TAI by an integral number of seconds. Mark Calabretta ATNF

### Re: Risks of change to UTC

to read the mountain of email, with its many irrelevant diversions, that has accumulated over the last 6 years - somewhat over 9MB by my count. Instead, I (re-)suggest that you (someone) write a position paper, or at least a FAQ, summarising your points. Mark Calabretta ATNF

### Re: Risks of change to UTC

is to ask - what if we increased the official length of the day before the situation gets so far out of hand, to 86400 plus some fraction of a second? Mark Calabretta ATNF

### Re: building consensus

. A simple transition from the Julian leap year rule to the Gregorian rule (i.e. without calendrical discontinuity) would probably have been more saleable, especially to people with no interest in Easter. Mark Calabretta ATNF

### Re: building consensus

On Mon 2006/06/05 22:04:40 -0400, John Cowan wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL there was no 1845-12-31 in Manila, any more than there was a As magic tricks go I don't find this one very convincing - I can clearly see the rabbits behind your back. Mark Calabretta ATNF

### Re: building consensus

labelled EST and the other EDT, neither were official but either could still be used without ambiguity. At the other end of the season there will be two and both will be official. C.f. email from me dated 2006/01/13 on this subject. Mark Calabretta

### Leap-seconds, the epsilon perspective

is 25 SI hours long, epsilon would be one hour but UTC would still function properly. Notably, updates to Epsilon would be as infrequent as ever. However, the world's timezones, especially those furthest from Greenwich, would need a modest adjustment - half an hour at most. Dr. Mark