Accounting for leap seconds for "this time value"

# Karl Cheng (9 years ago)

The current specification has this to say about the time value in dates:

"Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.

In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day."

What I would like to seek clarification about is if we were to do the following:

Math.floor(Date.now() / 1000) % 60;

Would complying with the specification mean that this value calculated for the "seconds" should not correspond with the time shown outside of JavaScript (because of leap seconds)? For example, if that code returns "30", would that mean that a clock following UTC should show a seconds value of "04"? At the moment, it seems that the implementations I have tested do not follow this.

The current specification has this to say about the time value in dates:

"Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.
> In time values leap seconds are ignored. It is assumed that there are
> exactly 86,400,000 milliseconds per day."


What I would like to seek clarification about is if we were to do the
following:

```js
Math.floor(Date.now() / 1000) % 60;
```

Would complying with the specification mean that this value calculated for
the "seconds" should not correspond with the time shown outside of
JavaScript (because of leap seconds)?  For example, if that code returns
"30", would that mean that a clock following UTC should show a seconds
value of "04"? At the moment, it seems that the implementations I have
tested do not follow this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150903/e8a59b95/attachment.html>

# Claude Pache (9 years ago)

That means that Date.now()/1000 is the [Unix time] (en.wikipedia.org/wiki/Unix_time, en.wikipedia.org/wiki/Unix_time), which can't represent leap seconds. In particular, each minute is assumed to have exactly 60 seconds, and thus it is impossible to represent 1981-06-30 23:59:60 UTC in JS (or in Unix time).

That means that `Date.now()/1000` is the [Unix time] (https://en.wikipedia.org/wiki/Unix_time <https://en.wikipedia.org/wiki/Unix_time>), which can't represent leap seconds. In particular, each minute is assumed to have exactly 60 seconds, and thus it is impossible to represent `1981-06-30 23:59:60 UTC` in JS (or in Unix time). 

—Claude


> Le 3 sept. 2015 à 11:40, Karl Cheng <qantas94heavy at gmail.com> a écrit :
> 
> The current specification has this to say about the time value in dates:
> 
> "Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day."
> 
> What I would like to seek clarification about is if we were to do the following:
> 
> ```js
> Math.floor(Date.now() / 1000) % 60;
> ```
> 
> Would complying with the specification mean that this value calculated for the "seconds" should not correspond with the time shown outside of JavaScript (because of leap seconds)?  For example, if that code returns "30", would that mean that a clock following UTC should show a seconds value of "04"? At the moment, it seems that the implementations I have tested do not follow this.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150903/32ac2c3c/attachment-0001.html>

# Michael McGlothlin (9 years ago)

Wouldn't the leap seconds be only formatting for display where as time stored in epochs is universal? If I'm on Mars the epochs value is the same whereas local time (on Mars) may have a totally different set of adjustments to keep the human readable time true to that planets rotation etc.

📱 Michael McGlothlin

Wouldn't the leap seconds be only formatting for display where as time stored in epochs is universal? If I'm on Mars the epochs value is the same whereas local time (on Mars) may have a totally different set of adjustments to keep the human readable time true to that planets rotation etc.


📱 Michael McGlothlin

> On Sep 3, 2015, at 5:06 AM, Claude Pache <claude.pache at gmail.com> wrote:
> 
> 
> That means that `Date.now()/1000` is the [Unix time] (https://en.wikipedia.org/wiki/Unix_time), which can't represent leap seconds. In particular, each minute is assumed to have exactly 60 seconds, and thus it is impossible to represent `1981-06-30 23:59:60 UTC` in JS (or in Unix time). 
> 
> —Claude
> 
> 
>> Le 3 sept. 2015 à 11:40, Karl Cheng <qantas94heavy at gmail.com> a écrit :
>> 
>> The current specification has this to say about the time value in dates:
>> 
>>> "Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day."
>> 
>> What I would like to seek clarification about is if we were to do the following:
>> 
>> ```js
>> Math.floor(Date.now() / 1000) % 60;
>> ```
>> 
>> Would complying with the specification mean that this value calculated for the "seconds" should not correspond with the time shown outside of JavaScript (because of leap seconds)?  For example, if that code returns "30", would that mean that a clock following UTC should show a seconds value of "04"? At the moment, it seems that the implementations I have tested do not follow this.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150903/3469b5a4/attachment.html>