1254041 - Date.prototype.setMilliseconds doesn't work correctly with negative time on ICT(UTC+7)

Status: RESOLVED DUPLICATE of bug 1346211

(Core :: JavaScript Engine, defect)

Description

[Loïc Faure-Lacroix]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20160307055558

Steps to reproduce:

I created a date like this: 

var h = new Date(Date.UTC(1969, 11, 31, 23, 0))

This gives a date with a negative milliseconds count -3600000

Trying to append 30 minutes will change the date to -1800000, changing the date again with 30 minutes will move the date back to -3600000


Actual results:

If we try to add 30 minutes in a loop from a negative date, it will result in an infinite loop moving from -3600000 to -1800000,

from -3600000 doing h.setHours(h.getHours() + 1) will not change the date at all.


Expected results:

The date should have move 30 minutes forward or 1 hours forwards for hours... in milliseconds it should have reached "0". Instead it goes back 1 hours backwards. I tried to setHours(getHours() + 2) from -3600000 millis and it moves to 0. As if there was a leap hour.

Comment 1

[Loïc Faure-Lacroix]

This affect a quite common library fullcalendar.js, there is a method named "addMinutes" that uses the behaviour of adding minutes to change the hour... except it creates an infinite loop with this bug. A quick fix to this bug is to replace the method addMinutes with this:

  function addMinutes(d, n) {
    n *= 60000;
    if (d.getTime() + n === 0){
      d.setTime(0);
    } else {
      d.setMinutes(d.getMinutes() + n);
    }
    return d;
  }

Comment 2

[Tooru Fujisawa [:arai]]

Can you post a full testcase?
How does the loop look like?

I cannot reproduce the issue with following code:

  var h = new Date(Date.UTC(1969, 11, 31, 23, 0));
  for (var i = 0; i < 5; i++) {
    console.log(h.toUTCString());
    console.log(h.getTime());
    h.setMinutes(h.getMinutes() + 30);
  }

it gives following output on Firefox ESR 38.6.1, the value of h.getTime() doesn't get back to -3600000.

> "Wed, 31 Dec 1969 23:00:00 GMT"
> -3600000
> "Wed, 31 Dec 1969 23:30:00 GMT"
> -1800000
> "Thu, 01 Jan 1970 00:00:00 GMT"
> 0
> "Thu, 01 Jan 1970 00:30:00 GMT"
> 1800000
> "Thu, 01 Jan 1970 01:00:00 GMT"
> 3600000


Also, the addMinutes function you posted looks buggy, it adds |n * 60000| minutes.

Comment 3

[Loïc Faure-Lacroix]

yes, the addMinutes should be:

  function addMinutes(d, n) {
    if (d.getTime() + (n * 60000) == 0) {
      d.setTime(0)
    } else {
      d.setMinutes(d.getMinutes() + n);
    }
    return d;
  }

I'm on Firefox 38.6.1 too. Could it be caused by some optimizations? Technically, it should be a bug in SpiderMonkey and not firefox... I have spidermonkey 24.2.0 installed.

Comment 4

[Tooru Fujisawa [:arai]]

are you running the script on spidermonkey 24.2.0, or on Firefox 38.6.1?

also, please post a full testcase, not only addMinutes function.

Comment 5

[Loïc Faure-Lacroix]

Attachment: scratchpad.js

Test Case

Comment 6

[Loïc Faure-Lacroix]

Attachment: Screenshot from 2016-03-07 20-06-27.png

Screenshot of results

Comment 7

[Tooru Fujisawa [:arai]]

It's not reproducible here.

I get following output:

  -1
  0
  1
  0
  -1
  0
  3600000
  10799999
  10800000
  18000000

on following configurations:
  * Firefox ESR 38.6.1 64bit on OSX 10.11.3 (timezone: Japan)
  * Firefox ESR 38.6.1 64bit on Debian GNU/Linux 8.3 (timezone: Asia/Tokyo)

It could be a timezone issue (daylight saving time?).
which timezone are you using?

Comment 8

[Loïc Faure-Lacroix]

Ok, I just tried with other timezones and that could be the real reason... I can't reproduce the bug with other timezones... I'm in ICT(UTC+7) Ho Chi Minh. I checked on the net, and couldn't find a reason in 1969 or 1970 for that one hour leap between 1969 and 1970.

I can add my /etc/localtime file to reproduce the bug.

Comment 9

[Loïc Faure-Lacroix]

Attachment: localtime

Comment 10

[Tooru Fujisawa [:arai]]

Confirmed the issue with your localtime file, on Firefox 38.6.1 (64bit) on Fedora 23.

It happens also on Nightly Firefox (64bit) and js shell (64bit) for today's mozilla-central.

Comment 11

[Loïc Faure-Lacroix]

I also should add that the issue isn't present on Chromium.

Comment 12

[Loïc Faure-Lacroix]

Also, the title might be a bit misleading. It affects all of setMilliseconds, setSeconds, setMinutes, setHours and probably setYears ... anything that modify the time seems to be affected.

Comment 13

[Tooru Fujisawa [:arai]]

looks like it's a issue related to Daylight Saving Time and maybe our implementation for it.

  var a = new Date(0);
  console.log(a);
  a = new Date(-1);
  console.log(a);

output is following:

  Thu Jan 01 1970 08:00:00 GMT+0800 (IDT)
  Thu Jan 01 1970 06:59:59 GMT+0700 (IDT)

so, that "1 hour" difference seems to be related.

Comment 14

[André Bargull [:anba]]

Dup'ing forward to bug 1346211 which should have fixed this problem. Please reopen if the issue is still present. Thanks!