Discuss
  • Date Object Doesn't Work.

Date Object Doesn't Work.

# Garrett Smith (11 years ago)

Yesterday, I posed the question about an event starts at 2am, 2014, and ends immediately after 3 am, on May 9, how long is it?

The event, in that case, should be 23 hours due to 1h DST loss. ("spring forward"). But then I noticed more anomalies:

<!doctype html> <head> <title>test DST 1</title>

<style>

head, script { display: block; white-space: pre; font-family: monospace; } </style> <script>

var d = new Date(2013, 02, 10), d2 = new Date(2013, 02, 10); d.setHours(1); d2.setHours(2);

function showResult() { document.getElementById("out"). firstChild.data = "d: " + d.toString() + "\nd2: " + d2.toString() + "\nd2 - d: " + (d2 - d) } window.onload = showResult; </script> </head>

<h2>result</h2> <pre id='out'>-</pre> </body> </html>

Chrome, Opera: d: Sun Mar 10 2013 01:00:00 GMT-0800 (PST) d2: Sun Mar 10 2013 01:00:00 GMT-0800 (PST) d2 - d: 0

Safari: d: Sun Mar 10 2013 01:00:00 GMT-0800 (PST) d2: Sun Mar 10 2013 03:00:00 GMT-0700 (PDT) d2 - d: 3600000

Firefox: d: Sun Mar 10 2013 01:00:00 GMT-0800 (PDT) d2: Sun Mar 10 2013 03:00:00 GMT-0700 (PDT) d2 - d: 3600000

What are Opera and Chrome doing?

Here in CA, we recognize DST, and so 0 would be wrong, as 2am gets set forward to 3am but the offset changes, too.

I believe Safari is correct here.

Now from 2am - 3am, the difference should be 0 because 2am gets set forward to 3am.

<!doctype html> <head> <title>test DST 2</title>

<style>

head, script { display: block; white-space: pre; font-family: monospace; } </style> <script>

var r = new Date(2013, 02, 10), r2 = new Date(2013, 02, 10); r.setHours(2); r2.setHours(3);

function showResult() { document.getElementById("out"). firstChild.data = "r: " + r.toString() + "\nr2: " + r2.toString() + "\nr2 - d: " + (r2 - r) } window.onload = showResult; </script> </head>

<h2>result</h2> <pre id='out'>-</pre> </body> </html>

Firefox: r: Sun Mar 10 2013 03:00:00 GMT-0700 (PDT) r2: Sun Mar 10 2013 03:00:00 GMT-0700 (PDT) r2 - d: 0

Safari: r: Sun Mar 10 2013 03:00:00 GMT-0700 (PDT) r2: Sun Mar 10 2013 04:00:00 GMT-0700 (PDT) r2 - d: 3600000

Opera, Chrome: r: Sun Mar 10 2013 01:00:00 GMT-0800 (PST) r2: Sun Mar 10 2013 03:00:00 GMT-0700 (PDT) r2 - d: 3600000

Firefox seems to get this right, forwarding 2am to 3am.

What is going on with the others?

# Andrea Giammarchi (11 years ago)

While I agree we should expect consistent results, you might get more consistent one via UTC time, i.e.

var r = new Date(2013, 02, 10),
    r2 = new Date(2013, 02, 10),
    diff = 7;
r.setUTCHours(2 + diff);
r2.setUTCHours(3 + diff);

Above operation will actually show 1 hour difference in all browsers (visually 2 due -8 VS -7 zone)

# Norbert Lindenberg (11 years ago)

As Luke phrased it two years ago: “The current [ES 5.1] spec text allows implementations to be as wrong as they'd like about daylight savings adjustments, but constrains how correct they should try to be. This is somewhat counterintuitive, and in practice, has not succeeded in producing consensus between browsers.” [1]

The ES6 spec [2, 3] has since been changed to encourage implementors to use best available information, but maybe implementors haven’t taken advantage of this yet. Bug reports against the implementations may help.

[1] esdiscuss/2012-March/020830 [2] people.mozilla.org/~jorendorff/es6-draft.html#sec-local-time-zone-adjustment [3] people.mozilla.org/~jorendorff/es6-draft.html#sec-daylight-saving-time-adjustment

Norbert

# Garrett Smith (11 years ago)

On 5/28/14, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

Hi Andrea -

While I agree we should expect consistent results, you might get more consistent one via UTC time, i.e.

var r = new Date(2013, 02, 10),
    r2 = new Date(2013, 02, 10),
    diff = 7;
r.setUTCHours(2 + diff);
r2.setUTCHours(3 + diff);

Above operation will actually show 1 hour difference in all browsers (visually 2 due -8 VS -7 zone)

The difference between 2am and 3am on that date, for this timezone (America/Los_Angeles), is zero. diff isn't needed to calculate DST-free difference.

r Sun Mar 10 2013 01:00:00 GMT-0800 (PST)

Given arbitrary dates and timezones, tzo difference might or might not cross DST and that might be adjusted by the user.

But calculating DST-free difference seems like a safer bet. And so the way to do that would be to send a local date but treat it as UTC.

# Andrea Giammarchi (11 years ago)

All I was saying is that you should always do dates operations through UTC values which has consistent behavior across engines.