GERRY ASHTON wrote: >I guess "reduced to scalar value" means applying a procedure such as:
Yes, that's about it. I wouldn't describe the day spans as "seconds excluding leap seconds"; better to put it as "86400 times the number of days". I would use an expression such as "86400*MJDN + 3600*H + 60*M + S". >So SV seems inadmissable in any system that is expected to accurately >label events during the leap seconds. As I've already said, that scalar value is not sufficient to unambiguously represent UTC times. We're all familiar with time_t's inadequacy in that regard. But it's legitimate to use that kind of scalar value for other purposes. That is how TAI-UTC is defined, not just in the leap seconds era but also in the defining expressions for the rubber-seconds era that can be seen in tai-utc.dat. When converting from TAI to UTC, it is not sufficient to know only TAI and the instantaneous value of TAI-UTC. This is true not only of the TAI-UTC that I have described, which changes value at the end of a leap second, but also of Warner's variant TAI-UTC which changes value at the start of a leap second. In the vicinity of a month end one requires more information, amounting to *two* TAI-UTC values, those for the two months involved. So in practice one tends not to tie a TAI-UTC value to an instant or a second, but to some larger time unit: a minute, a day, or a month. In that context it's rather pointless to argue about what value TAI-UTC takes during a leap second. It only matters for the theory. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
