3 ms·
> Does one second matter to your application? Yes. And it's not just real-time; even when just displaying dates and times, an off-by-one error at any granulari
by _greim_ 10y ago
> Does one second matter to your application?
Yes. And it's not just real-time; even when just displaying dates and times, an off-by-one error at any granularity can bump it into the next year.
I guess what I'm wondering is how does the decision to add a leap second here or there find its way into system clocks, such that it knows whether:
new Date(1483228800000).getUTCFullYear()
...is 2016 or 2017?
- brudgers 10y agois 2016 or 2017? Depends on where one is. It takes 24 hours for the New Year to propagate. The maximum error during propagation is < 0.00115741% Assuming that .getUTCFullYear() is accurate, the maximum error for a leap second is: 1 / (365 * 24 * 3600) = 3.1709791983764586e-8 The duration of that error is one second. Curious about the nature of the application.
- rspeer 10y agoJavaScript timestamps are POSIX timestamps times 1000, and POSIX timestamps have to be corrected for leap seconds at the OS level, not in the application. The advantage of this is that 1483228800000 is definitely the start of 2017 (and in general, UTC days start on multiples of 86400 seconds, or 86400000 in JS). The disadvantage is that Date(1483228799999) could happen twice, and the first time it would be followed by Date(1483228799000). In your application, you have to be able to cope with time going backwards for a moment. (But this is already true whenever your system contacts an NTP server.)