Node: Date Bug

[willin]

• Version: 7.6.0 - 7.7.1
• Platform: osx ubuntu
• Subsystem: 10.12 16.04

perhaps it is by timezone offset

different:

new Date('2017-03-03T11:50:00')/1000
// node: 1488541800
// chrome: 1488513000

almost same:

new Date()/1000
// node: 1488514430.708
// chrome: 1488514431.856

[willin]

@mscdex

add a example.

in previous version it not happened

[mscdex]

I get the same value in both node and Chrome for the first example. The second example will be different obviously because new Date() won't execute at the exact same time in both places.

[willin]

@mscdex my timezone +8 Asia,Beijing

Chrome/58.0.3026.3

[KenanY]

@willin In the second part of your screenshot, you appear to be doing new Date('2017-03-03T12:05:00')/1000 (note the 12:05 instead of 11:50). Is that intentional?

[Trott]

I get the same value in both node and Chrome.

Me too. The two time stamps @willin is getting are exactly 8 hours apart which matches their timezone offset, so that seems a likely possible cause. Maybe the timezone set in their browser is different than (and overriding) that set on their system?

[gireeshpunathil]

I guess the problem is that Chrome converts the date based on the timezone, while node does not, and the question is, should we or not. As observed below, node gets the same stamp irrespective of the zone

Eastern:

$ date; ./node -e 'console.log(new Date("2017-03-03T11:50:00")/1000);'
Fri Mar  3 06:19:31 EST 2017
1488541800

India:

#date; ./node -e 'console.log(new Date("2017-03-03T11:50:00")/1000);'
Fri Mar  3 16:49:59 IST 2017
1488541800

[Trott]

@gireeshpunathil How could that display issue cause the results being reported by @willin? How could it explain why others are unable to reproduce @willin's result? Wouldn't everyone else (or at least people at a time offset from UTC) be seeing the same issue if it were somehow being caused by what you are describing? I'm specifically talking about how this returns different seconds-since-epoch values in Node.js and Chrome for @willin but not for me or @mscdex:

new Date('2017-03-03T11:50:00')/1000
// node: 1488541800
// chrome: 1488513000

[Trott]

@willin wrote:

Chrome/58.0.3026.3

Ah! So this is Chrome Canary?

I installed Chrome Canary and I too am seeing the behavior you describe.

I would characterize this as a Chrome issue/question, as I'm getting results that conform with Node.js on Chrome 56.

[Trott]

```js
new Date('2017-03-03T11:50:00')/1000
// node: 1488541800
// chrome 56 (stable): 1488541800
// chrome 58 (canary): 1488513000 <- wha?!?!

[ChALkeR]

@Trott, does specifying the tz change anything?

[Trott]

specifying the tz change anything?

Being explicit about the offset causes all three to be consistent:

new Date('2017-03-03T11:50:00-05:00')/1000
// node     : 1488559800
// chrome 56: 1488559800
// chrome 58: 1488559800

[willin]

@Trott dev version

[Trott]

@nodejs/v8 Bug? Feature? Neither?

[bnoordhuis]

Is the question why Chrome and Node disagree? V8 recently implemented ES6 timezone handling (v8/v8@d31c5410c4fdfc5eb66582892d5e3ecd3706bd58). That change probably exists in Chrome 58 but not yet in Node.

[Trott]

Ah! Thanks. So, different behavior, yes, but not a bug, no. And eventually, this new behavior will be in Node.js and Chrome current. I'm going to close this. Feel free to comment or re-open if anyone feels that's not the right thing to do.

[willin]

@Trott @bnoordhuis

what i'm doing now is

new Date((x.timestamp - 28800) * 1000)

for all front browser requests now.

how to make it compatible?

[willin]

now v8.0.0 but still so....

[refack]

Hello @willin , see if the information in MDN about DateTimeFormat helps.
A good strategy might be to only do calculations with dates in UTC, and display them in the user's timezone.