Closed Bug 1392657 Opened 7 years ago Closed 7 years ago

Date.prototype.setDate behavior mismatch between browsers around DST switch

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
55 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 830304

People

(Reporter: ciro_xm, Unassigned)

Details

(Whiteboard: [parity-chrome][parity-edge]) 

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170814072924

Steps to reproduce:

Run this test function:

*Require momentjs

//Simplified version of the code
function testBug(){
    var intValue = null;
    var mData = moment(20171010, 'YYYYMMDD');
    for (var i = 1; i <= 10; i++) {

        intValue = parseInt(mData.format('YYYYMMDD'));

        console.log("======================================================");
        console.log("i", i);
        console.log("Date", mData.toDate());
        console.log("intValue", intValue);

        mData.add(1, 'd');
    }
};


Actual results:

Watch i 5 and 6. This repeat 20171014. Why? Chrome and Edge don't have this behavour.

12:28:13.591 ======================================================  utils.js:1727:9
12:28:13.591 i 1  utils.js:1728:9
12:28:13.592 Date Date 2017-10-10T03:00:00.000Z  utils.js:1729:9
12:28:13.593 intValue 20171010  utils.js:1730:9
12:28:13.595 ======================================================  utils.js:1727:9
12:28:13.595 i 2  utils.js:1728:9
12:28:13.596 Date Date 2017-10-11T03:00:00.000Z  utils.js:1729:9
12:28:13.597 intValue 20171011  utils.js:1730:9
12:28:13.598 ======================================================  utils.js:1727:9
12:28:13.598 i 3  utils.js:1728:9
12:28:13.599 Date Date 2017-10-12T03:00:00.000Z  utils.js:1729:9
12:28:13.599 intValue 20171012  utils.js:1730:9
12:28:13.600 ======================================================  utils.js:1727:9
12:28:13.600 i 4  utils.js:1728:9
12:28:13.601 Date Date 2017-10-13T03:00:00.000Z  utils.js:1729:9
12:28:13.602 intValue 20171013  utils.js:1730:9
12:28:13.602 ======================================================  utils.js:1727:9
12:28:13.603 i 5  utils.js:1728:9
12:28:13.603 Date Date 2017-10-14T03:00:00.000Z  utils.js:1729:9
12:28:13.604 intValue 20171014  utils.js:1730:9
12:28:13.605 ======================================================  utils.js:1727:9
12:28:13.605 i 6  utils.js:1728:9
12:28:13.606 Date Date 2017-10-15T02:00:00.000Z  utils.js:1729:9
12:28:13.606 intValue 20171014  utils.js:1730:9
12:28:13.607 ======================================================  utils.js:1727:9
12:28:13.608 i 7  utils.js:1728:9
12:28:13.608 Date Date 2017-10-16T01:00:00.000Z  utils.js:1729:9
12:28:13.609 intValue 20171015  utils.js:1730:9
12:28:13.610 ======================================================  utils.js:1727:9
12:28:13.610 i 8  utils.js:1728:9
12:28:13.610 Date Date 2017-10-17T01:00:00.000Z  utils.js:1729:9
12:28:13.611 intValue 20171016  utils.js:1730:9
12:28:13.611 ======================================================  utils.js:1727:9
12:28:13.612 i 9  utils.js:1728:9
12:28:13.612 Date Date 2017-10-18T01:00:00.000Z  utils.js:1729:9
12:28:13.613 intValue 20171017  utils.js:1730:9
12:28:13.613 ======================================================  utils.js:1727:9
12:28:13.614 i 10  utils.js:1728:9
12:28:13.614 Date Date 2017-10-19T01:00:00.000Z  utils.js:1729:9
12:28:13.615 intValue 20171018


Expected results:

Chrome and Edge results:

utils.js:1727 ======================================================
utils.js:1728 i 1
utils.js:1729 Date Tue Oct 10 2017 00:00:00 GMT-0300 (Hora oficial do Brasil)
utils.js:1730 intValue 20171010
utils.js:1727 ======================================================
utils.js:1728 i 2
utils.js:1729 Date Wed Oct 11 2017 00:00:00 GMT-0300 (Hora oficial do Brasil)
utils.js:1730 intValue 20171011
utils.js:1727 ======================================================
utils.js:1728 i 3
utils.js:1729 Date Thu Oct 12 2017 00:00:00 GMT-0300 (Hora oficial do Brasil)
utils.js:1730 intValue 20171012
utils.js:1727 ======================================================
utils.js:1728 i 4
utils.js:1729 Date Fri Oct 13 2017 00:00:00 GMT-0300 (Hora oficial do Brasil)
utils.js:1730 intValue 20171013
utils.js:1727 ======================================================
utils.js:1728 i 5
utils.js:1729 Date Sat Oct 14 2017 00:00:00 GMT-0300 (Hora oficial do Brasil)
utils.js:1730 intValue 20171014
utils.js:1727 ======================================================
utils.js:1728 i 6
utils.js:1729 Date Sun Oct 15 2017 01:00:00 GMT-0200 (Horário brasileiro de verão)
utils.js:1730 intValue 20171015
utils.js:1727 ======================================================
utils.js:1728 i 7
utils.js:1729 Date Mon Oct 16 2017 01:00:00 GMT-0200 (Horário brasileiro de verão)
utils.js:1730 intValue 20171016
utils.js:1727 ======================================================
utils.js:1728 i 8
utils.js:1729 Date Tue Oct 17 2017 01:00:00 GMT-0200 (Horário brasileiro de verão)
utils.js:1730 intValue 20171017
utils.js:1727 ======================================================
utils.js:1728 i 9
utils.js:1729 Date Wed Oct 18 2017 01:00:00 GMT-0200 (Horário brasileiro de verão)
utils.js:1730 intValue 20171018
utils.js:1727 ======================================================
utils.js:1728 i 10
utils.js:1729 Date Thu Oct 19 2017 01:00:00 GMT-0200 (Horário brasileiro de verão)
utils.js:1730 intValue 20171019
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Thanks for the bug report! Can you make a full test case in a JS file that embeds the right version of moment.js and attach it to this bug, please?
(In reply to Benjamin Bouvier [:bbouvier] from comment #1)
> Thanks for the bug report! Can you make a full test case in a JS file that
> embeds the right version of moment.js and attach it to this bug, please?

Sure.

<html>
	<head>
		<script type="text/javascript" src="https://momentjs.com/downloads/moment-with-locales.js"></script>
	</head>
	<body>
		<script>
			function testBug(){
				var intValue = null;
				var mData = moment(20171010, 'YYYYMMDD');
				for (var i = 1; i <= 10; i++) {

					intValue = parseInt(mData.format('YYYYMMDD'));

					console.log("======================================================");
					console.log("i", i);
					console.log("Date", mData.toDate());
					console.log("intValue", intValue);

					mData.add(1, 'd');
				}
			};
			testBug();
		</script>
	</body>
</html>
doesn't happen for me.
isn't it something related to DST?  (I'm on JST that doesn't have DST)
https://en.wikipedia.org/wiki/Daylight_saving_time

which timezone are you using on your PC?
is there any chance that DST ends around 14 Oct for you this year?
https://en.wikipedia.org/wiki/Daylight_saving_time_by_country

also, I think the issue would persist even if you don't call parseInt.
Flags: needinfo?(ciro_xm)
(In reply to Tooru Fujisawa [:arai] from comment #3)
> is there any chance that DST ends around 14 Oct for you this year?

or DST starts.
oh, there seems to be that information in the Chrome and Edge's log

> utils.js:1729 Date Sat Oct 14 2017 00:00:00 GMT-0300 (Hora oficial do Brasil)
> ...
> utils.js:1729 Date Sun Oct 15 2017 01:00:00 GMT-0200 (Horário brasileiro de verão)
Summary: Parseint problem? → Moment.prototype.add and Moment.prototype.format behavior mismatch between browsers around DST switch
Whiteboard: [parity-chrome][parity-edge]
reproduced the issue by setting TZ='Brazil/East' env variable

code:

function testBug(){
  var mData = moment('20171010', 'YYYYMMDD HHmmss');
  for (var i = 1; i <= 10; i++) {
    console.log(i, mData.format('YYYYMMDD HHmmss'));
    mData.add(1, 'd');
  }
};
testBug();

output:

1 20171010 000000
2 20171011 000000
3 20171012 000000
4 20171013 000000
5 20171014 000000
6 20171014 230000
7 20171015 230000
8 20171016 230000
9 20171017 230000
10 20171018 230000
Flags: needinfo?(ciro_xm)
Status: UNCONFIRMED → NEW
Ever confirmed: true
code:
  var mData = createLocal('20171014', 'YYYYMMDD');
  console.log(mData.format('YYYYMMDD HHmmss ZZ'));
  console.log(mData._d.toUTCString());
  mData.add(1, 'd');
  console.log(mData.format('YYYYMMDD HHmmss ZZ'));
  console.log(mData._d.toUTCString());

result on SpiderMonkey:
  20171014 000000 -0300
  Sat, 14 Oct 2017 03:00:00 GMT
  20171014 230000 -0300
  Sun, 15 Oct 2017 02:00:00 GMT

result on Chrome:
  20171014 000000 -0300
  Sat, 14 Oct 2017 03:00:00 GMT
  20171015 010000 -0200
  Sun, 15 Oct 2017 03:00:00 GMT
here's reduced testcase without moment.js:

code:
  var d = new Date(1507950000000);
  console.log(d.toString());
  d.setDate(15);
  console.log(d.toString());

result on SpiderMonkey with TZ='Brazil/East':
  Sat Oct 14 2017 00:00:00 GMT-0300
  Sat Oct 14 2017 23:00:00 GMT-0300

result on Chrome with TZ='Brazil/East':
  Sat Oct 14 2017 00:00:00 GMT-0300 (-03)
  Sun Oct 15 2017 01:00:00 GMT-0200 (-02)

result on es6draft with TZ='Brazil/East':
  Sat Oct 14 2017 00:00:00 GMT-0300 (BRT)
  Sun Oct 15 2017 01:00:00 GMT-0200 (BRST)

so, Date.prototype.setDate behaves differently when it enters/leaves DST.
Summary: Moment.prototype.add and Moment.prototype.format behavior mismatch between browsers around DST switch → Date.prototype.setDate behavior mismatch between browsers around DST switch
Looks similar to bug 1071011, bug 1084434, bug 1342853. The patch in bug 830304 will probably fix this issue.
(In reply to André Bargull from comment #9)
> Looks similar to bug 1071011, bug 1084434, bug 1342853. The patch in bug
> 830304 will probably fix this issue.

indeed, the issue disappears with the patch applied.

result on SpiderMonkey with TZ='Brazil/East':
  Sat Oct 14 2017 00:00:00 GMT-0300
  Sun Oct 15 2017 01:00:00 GMT-0200

and also 20171014 doesn't repeat on the initial testcase.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.