3 ms·

Question for the experts. Say I'm writing a bunch of code for date/time stuff in JavaScript, using the built-in `Date` API. Is this something I need to worry ab

by _greim_ 10y ago

Question for the experts. Say I'm writing a bunch of code for date/time stuff in JavaScript, using the built-in `Date` API. Is this something I need to worry about? I've read countless "falsehoods programmers believe about time" blog posts but they tend to not explain the why of it.

deleted 10y ago
[deleted]
ue_ 10y ago
They also don't offer or explain any solutions. I've found the 'falsehoods' articles are good for generating discussion and not much else. They make the writer feel clever, without having to do anything.
brudgers 10y ago
I'm making to no claim to being an expert. Nevertheless, my question is "Does one second matter to your application? If so, how does Javascript's single threading, garbage collection, and default asynchronous programming idioms fit with the needs of a real or near real time system?"
- _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 ago
    is 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 ago
    JavaScript 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.)

by _greim_ 10y ago

deleted 10y ago

[deleted]

ue_ 10y ago

They also don't offer or explain any solutions. I've found the 'falsehoods' articles are good for generating discussion and not much else. They make the writer feel clever, without having to do anything.

brudgers 10y ago

I'm making to no claim to being an expert. Nevertheless, my question is "Does one second matter to your application? If so, how does Javascript's single threading, garbage collection, and default asynchronous programming idioms fit with the needs of a real or near real time system?"

_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 ago
  is 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 ago
  JavaScript 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.)