setSeconds doesn't work correct with time conversion

[sruetzler]

• Version: 4.4.5
• Platform: Ubuntu 14.04.4 x63:64
• Subsystem:

The problem still exists in 6.2.0

Tested in Timezone Europe/Berlin
Example Code:

date = new Date(1445734861000); //Sun Oct 25 2015 02:01:01 GMT+0100 (CET)
//Right after switching daylight saving off

date.setSeconds(0) //Sun Oct 25 2015 02:01:00 GMT+0200 (CEST)
date.getTime() //1445731260000

The date is now almost one hour before switching daylight saving off.
Expected date: Sun Oct 25 2015 02:01:00 GMT+0100 (CET)
At least in v0.10.32 this works.

[targos]

Looks like it is related to the following V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=3637&q=setSeconds&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Component%20Stars

[sruetzler]

Yes I think this is the same problem.
The V8 issue priority is medium and it's open since Oct 2014.
For us this is a critical error is there a known workaround for this problem.

[jasnell]

@targos ... is this still an issue?

[sruetzler]

In node 6.10.3 this is still not working

[targos]

Yes, this is still an issue, but we cannot fix it directly in Node

[apapirovski]

@nodejs/v8 Anyone know what could be done to resolve this issue? If anything? Seems like it's partially a spec problem but it's important to note that other browsers implement this differently.

[hashseed]

The spec seems pretty clear on this one and hinges on LocalTZA. You could use Date.prototype.setUTCSeconds to work around this problem.

[apapirovski]

Thanks @hashseed. Sounds like we should close on our end. There's an issue in V8 if anyone wants to track although it doesn't seem like it'll see much movement.

[bnoordhuis]

The spec seems pretty clear on this one and hinges on LocalTZA.

Maybe I misunderstand but consider this:

> var d = new Date(1445734861000)

> d.getSeconds()
1

> d.getTimezoneOffset()
-60

> d.setSeconds(0)
1445731260000

# or:
> d.getTime() - d.setSeconds(0)
3601000

> d.getTimezoneOffset()
-120  # bad

V8 computes the local time offset once in PosixDefaultTimezoneCache::LocalTimeOffset() and caches it. Is the timezone jump a DST thing then? Because setting e.g. TZ=UTC-1 (no DST) fixes it.

[apapirovski]

I'm just skimming this but I think this is related to LocalTime in the spec:

When tlocal represents local time repeating multiple times at a negative time zone transition (e.g. when the daylight saving time ends or the time zone adjustment is decreased due to a time zone rule change) or skipped local time at a positive time zone transitions (e.g. when the daylight saving time starts or the time zone adjustment is increased due to a time zone rule change), tlocal must be interpreted with the time zone adjustment before the transition.

(link above per @hashseed)

[bnoordhuis]

Yep, I saw the note that "UTC(LocalTime(t)) is not necessarily always equal to t" and that's no understatement because d.setSeconds(d.getSeconds()) exhibits the same timezone jump.

I wouldn't call it intuitive but I guess it is conforming.

[hashseed]

Yes. There is a DST jump at precisely that time.

What setSeconds does is that it converts the time into UTC based on the time offset at that time. After it has calculated the new time, it converts the time back to local time based on the time offset at the new time.

The time offsets differ by an hour according to ICU.