On 2015-01-19, fm@fr.invalid <fm@fr.invalid> wrote: > William Unruh <un...@invalid.ca> wrote: >> On 2015-01-19, Mike S <mi...@flatsurface.com> wrote: >>> On 1/18/2015 6:04 PM, William Unruh wrote: >>> >>>> UTC always has 86400 seconds per year. >>> >>> You clearly don't understand how leap seconds work. You're embarrassing >>> yourself now. When there's a leap second, there are 86401 SI seconds in >> >> I AM clearly embarrasing myself, since 86400 is the number of seconds >> per SAY not year. Slight difference! >> >> Of course there are 86401 seconds in a day including a leap second. But >> UTC only sees 86400. It forgets about one of them. > > I am not sure what you mean by "sees", but I cant figure a meaning > that would be compatible with the fact that UTC clearly identifies > 86401 seconds on the day the leap second occurs.
If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. > > Maybe the confusion arises from considering UTC dates as > "time interval" quantities, which they are not, rather than timescale > readings. TAI days have 86400s, UTC days may have 86401 seconds ; > so it happens that when TAI reads 00h00:00, UTC reads 23:59:60. TAI does not as far as I know, have a concept of days. It has seconds. If you want to convert those seconds into things like days, months, etc, that is up to you. So, if we count utc seconds we have 1435733999 1435734000 1435734000 1435734001 ... That is what I mean. > That is what makes computing time intervals more complicated in > UTC than in TAI but neither TAI nor UTC is defined by the number > of seconds elapsed since an epoch. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
