42 ms·

Ignoring leap seconds will not make them disappear :-) They belong to UTC not to ECMA-262. Therefore, whenever we compute the difference between two UTC times,

by adg001 14y ago

Ignoring leap seconds will not make them disappear :-) They belong to UTC not to ECMA-262. Therefore, whenever we compute the difference between two UTC times, we should really account for any leap second.

VMG 14y ago
For the purpose of calculating milliseconds between midnights of different days, you can however assume them to be multiples of 862e5 in JavaScript Date.UTC. You just have to keep in mind that JavaScript UTC != Real UTC Edit: clarification
- adg001 14y ago
  No, you cannot. If you do it, your UTC time difference might be one or more seconds off. And this is not what you want, if you need to rely upon that quantity. Only one Coordinated Universal Time exists: it is the UTC standard. ECMA-262 is the specification of a scripting language, with tons of interesting features but with a very poor understanding of what UTC is. UTC is based on TAI. Whenever we need to compute time differences of UTC times, we need to account for leap seconds implementing TAI. Implementations are available in a number of languages and very easy to port: - C http://cr.yp.to/libtai.html http://cr.yp.to/libtai.html - Haskell http://hackage.haskell.org/packages/archive/time/1.4/doc/html/src/Data-Time-Clock-TAI.html http://hackage.haskell.org/packages/archive/time/1.4/doc/htm... - Erlang https://github.com/secyoure/taider https://github.com/secyoure/taider Full disclosure: author of the Erlang TAI library here.
  - VMG 14y ago
    I completely agree - but as you point out, JavaScript doesn't use proper UTC but a simplified version that does not account for leap seconds. Let's call it Date.UTC. In Date.UTC, there are no leap seconds and therefore the Day == 862e5 assumption holds and we can use it to calculate the difference between two dates measured in days, which is the point of the blog post. When doing arithmetic with real UTC, you are absolutely correct and we have to take leap seconds into account.

by adg001 14y ago

VMG 14y ago

For the purpose of calculating milliseconds between midnights of different days, you can however assume them to be multiples of 862e5 in JavaScript Date.UTC. You just have to keep in mind that JavaScript UTC != Real UTC Edit: clarification

adg001 14y ago
No, you cannot. If you do it, your UTC time difference might be one or more seconds off. And this is not what you want, if you need to rely upon that quantity. Only one Coordinated Universal Time exists: it is the UTC standard. ECMA-262 is the specification of a scripting language, with tons of interesting features but with a very poor understanding of what UTC is. UTC is based on TAI. Whenever we need to compute time differences of UTC times, we need to account for leap seconds implementing TAI. Implementations are available in a number of languages and very easy to port: - C http://cr.yp.to/libtai.html http://cr.yp.to/libtai.html - Haskell http://hackage.haskell.org/packages/archive/time/1.4/doc/html/src/Data-Time-Clock-TAI.html http://hackage.haskell.org/packages/archive/time/1.4/doc/htm... - Erlang https://github.com/secyoure/taider https://github.com/secyoure/taider Full disclosure: author of the Erlang TAI library here.
- VMG 14y ago
  I completely agree - but as you point out, JavaScript doesn't use proper UTC but a simplified version that does not account for leap seconds. Let's call it Date.UTC. In Date.UTC, there are no leap seconds and therefore the Day == 862e5 assumption holds and we can use it to calculate the difference between two dates measured in days, which is the point of the blog post. When doing arithmetic with real UTC, you are absolutely correct and we have to take leap seconds into account.