> It's tricky. Yes.
> Bulletin C is pretty clear about when it thinks TAI-UTC changes: Yes. > However, since there isn't any TAI time with a :60 seconds label, Yes. > it doesn't make much sense to have a defined delta for the last UTC second of > 2016. No. The delta is defined "until further notice". Therefore the delta is defined just fine during all of 2016, including *during* the positive leap second. The delta changes only as of 1-Jan-2017 UTC, which is why there is a leap second in the first place. In other words, the change in delta is what *causes* the leap second to exist. This works fine for both positive (-1 change in delta) and negative leap seconds (+1 change in delta). Another way to look at it is imagine in the distant future if we needed 3 or 5 or 20 leap seconds every month. The delta would still change by an integer but it would be greater than 1. There would be several positive leap seconds on that last day, 23:59:60, 23:59:61, 23:59:62. This does not mean time changes slowly. This does not mean the delta is undefined. It means the delta this month and the delta next month *are* precisely defined and this alone is what creates the addition or subtraction of multiple seconds in the last UTC minute of the month. A conventional leap second table has all the information you need to accomplish this and there is no problem in perfectly mapping TAI to UTC to TAI in all cases. So I see no reason or need to pick on "delta" as being in an indeterminate state during a leap second. We have enough exceptions with leap second handling as it is. Let's not create more confusion. /tvb _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
