> but I've always thought the > instant of the change was unambiguous, and that it was > instantaneous in both cases.
Correct. > I've only shown half-second increments, but in the limit, in the > positive case, TAI-UTC would be precisely 35 for every instant of > the second numbered 60, and changes to 36 at the first instant of > 00:00:00 UTC. Similarly, in the negative case, it's 35 for all > of 23:59:58, and again changes at the first instant of 00:00:00. Correct. And the fraction- or half-second technique is useful to illustrate this. > (For me this > helps explain the oddity that leap second tables typically list > the days *after* what feels like the leap second days: the tables > list the first instant of each new TAI-UTC value, which ends up > being the instant after the "essential discontinuity".) Yes, I've thought the same. There is a wide variety of leap second table formats; in print, on the web, and in code. A good number encode the end of the month date (e.g., 6/30) and a good number encode the beginning of the month date (e.g., 7/1). At one level it doesn't really matter. But there are often subtle user-interface or programming or testing reason to choose one over the other. I used to have strong preferences, but now I more appreciate the extent of programmer creativity. Lookup tables that just deal with UTC leap seconds tend to use the 6/30 format. Tables that work with TAI and UTC or TAI-UTC tend to use the 7/1 format. Tables that were designed with positive leap seconds on the brain are more likely to use the 6/30 format. Given when leap seconds happen local time, those of US in the far west tend to think of leap seconds happening in 6/30 format while those from Paris to the far east tend to think of leap seconds happening in 7/1 format. Index-1 programmers (e.g., FORTRAN) may unconsciously use <=, or 6/30 format, while index-0 programmers (C) may think of <, or 7/1 format. Some tables encode if the leap is +1 or if the leap is -1. Some encode the length of the minute (59, 61). Some encode the length of the day (86399, 86400, 86401). Some tables use year and month only, some use year, month and day (redundant), some use MJD, some use JD, some use unix time_t, some use NTP time, some use GPS time. So there's a wide variety of formats. I'm working on a "best practices" document with a pile of examples of how it's done, and how to do it right. Also, lots of embarrassing examples from the web of how it's done wrong. /tvb _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
