Strange thing, different results in differente browser for a new Date().
In Chrome 45.0.2454.101 m:
new Date(2015,9,1)
Thu Oct 01 2015 00:00:00 GMT+0200 (W. Europe Daylight Time)
In Firefox 40.0.3 (default inspector/console)
new Date(2015,9,1)
Date 2015-09-30T22:00:00.000Z
Additional info
If I try in Firefox with the console of FIREBUG extension, works well like Chrome.
What's happening? Seems that Firefox doen'st count the offset, in fact it's 2 hour behind the correct date.
I did the test on other workstation and all seems to have this "bug".
IF you don't want the timezone offset to be included you can use Date.UTC
Note: Where Date is called as a constructor with more than one
argument, the specifed arguments represent local time. If UTC is
desired, use new Date(Date.UTC(...)) with the same arguments.
~MDN
Output from Firefox dev console:
> new Date(2015,9,1)
Date 2015-09-30T22:00:00.000Z // reproduces your problem, my local time is GMT+0200
> new Date(Date.UTC(2015,9,1))
Date 2015-10-01T00:00:00.000Z // UTC time
However 00:00:00 GMT+0200 and 22:00:00.000Z are just different ways to represent the timezone offset in Date's string representation. The difference is the method used when printing to console: most browsers use .toString() while Firefox uses .toISOString(). (Edited; previously stated that the toString method implementations are different which isn't true).
In both Chrome (Thu Oct 01 2015 00:00:00 GMT+0200) and Firefox (Date 2015-09-30T22:00:00.000Z) methods like .getDate() and .getMonth() return the same values (1 and 9 respectively). The Date objects are the same.
This is just the behavior of the debug console. The two date values you showed are both the same, and are the correct value. You're just seeing the local time in Chrome, while Firefox chooses to show the UTC time in the debug console.
More accurately, Chrome, IE, and most other browsers simply call .toString() on the object, while Firefox is calling .toISOString().
Note that Firefox has a bug that us showing the wrong name of the time zone (Standard instead of Daylight), but you can see the debugger value matches the ISO8601 UTC value.
Related
In the Australia/Sydney time zone, Firefox seems to give an incorrect time for toLocaleString on dates:
new Date("2019-04-04T01:12:38.553309+00:00").toLocaleString() gives "4/4/2019, 11:12:38 AM".
new Date("2019-04-04T01:12:38.553309+00:00").toString() gives correct result "Thu Apr 04 2019 12:12:38 GMT+1100 (AEDT)".
I've been able to reproduce this on my phone as well as my computer. I asked a colleague to test, and Firefox gave the correct output on his computer.
Chromium gives the correct time for toLocaleString.
Is this a bug in Firefox? Do I have some misconfiguration?
I assume the correct approach here is to use a 3rd party library like date-fns to format my Dates instead.
Update: for now I have switched to using dateFns.format(timestamp, 'yyyy/MM/dd HH:mm:ss'). We don't have any US customers anyway.
If I pass the unix milliseconds timestamp value for 1/1/1753 (at midnight) (-6847786800000) to the JavaScript Date() constructor in Chrome, the Date Chrome gives me looks really weird. I get other weirdness when I use the Date() constructor that takes seven parameters. Examples are below.
Chrome: new Date(-6847786800000): Mon Jan 01 1753 00:03:58 GMT-0456 (Eastern Standard Time)
Firefox: new Date(-6847786800000): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)
Note how Chrome made the time 3:58 and the timezone GMT-0456 (the weird timezone appears to be about the same amount as the weird time (4 minutes).)
Chrome: new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0456 (Eastern Standard Time)
Firefox: new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)
Note how Chrome gives me 0:00 for the time, but still has that GMT-0456 timezone.
Playing around with various dates, this odd behavior seems to start with dates before 1884 - not sure of the exact date. 1/1/1884 acts as you would expect, but 1/1/1883 gets this "off by 3:58" behavior.
Is this a bug or am I missing something?
I tested this on:
Chrome 67.0.3396.99 (Official Build) (64-bit);
Firefox 61.0 (64-bit);
IE 11 and Edge 42.17134.1.0 give the same results as Firefox
UPDATE
This does not look like a duplicate of Browsers, time zones, Chrome 67 Error to me. That question is talking about timezones being different. It uses 1900 as an example. I'm talking about the time being different. And it only affects stuff before 1884. It does not affect 1900 dates.
Why would changing the timezone change the actual time? I'm not a timezone wizard but that still seems wrong to me.
UPDATE
So yeah, probably a duplicate in some sense. Don't know for sure if Chrome changed it's behavior with this. But it does come down to the fact that right now Chrome will see old unix timestamps, before 11/18/1883 at 12:03:58 PM, as different points in time than other browsers. So watch out if you need to work with timestamps for old dates. I switched away from using timestamps to avoid this issue.
On the console in chrome browser of windows and Ubuntu I entered Date() object and I found both have a different way to write the timezone for that date.
Ubuntu:
"Thu Aug 10 2017 18:45:18 GMT+0530 (IST)"
Windows:
"Thu Aug 10 2017 18:45:18 GMT+0530 (India Standard Time)"
According to my use case the output on Ubuntu is correct, the time zone IST is what expected. But on windows it always shows up India Standard Time.
Is there a way to fix this for windows.
According to my use case the output on Ubuntu is correct
Neither of them is correct. Or incorrect. The string form of a Date from toString (which is what those appear to be) is almost completely unspecified. The only requirement is that it represent the date, and that Date() and Date.parse should be able to parse it.
If you want something reliable cross browser*, use toISOString.
* Obsolete browsers may not have toISOString. Even only vaguely-modern browsers do.
Chrome not giving a correct result on date conversion:
Date : "2017-05-22T14:00:00"
On doing this in chrome console:
new Date("2017-05-22T14:00:00");
Output is:
Mon May 22 2017 14:00:00 GMT+0530 (IST)
This is wrong because I am in IST. It should have rather given output as
Mon May 22 2017 19:30:00 GMT+0530 (IST)
Safari is giving correct results. Chrome was right before but I think latest update is having an issue.
Found that appending Z in date string results correct date value.
new Date("2017-05-22T14:00:00Z");
The input value is being interpreted correctly. ECMAScript 2015 (ES6) section 20.3.1.16 states:
If the time zone offset is absent, the date-time is interpreted as a local time.
This aligns with the ISO-8601 standard as well.
In previous versions of ECMAScript, UTC was assumed when no offset was provided. That goes against ISO-8601, and was implemented inconsistently across various environments.
If you want the input to be interpreted as UTC, then you should provide an offset, either +00:00, or Z as part of the input string.
However, if you are talking about how a Date object should be displayed when logged to the debug console, that is not defined in the spec. In some environments, you will see the output of date.toString(), which shows the local date and time in a non-standard format, and in other environments (such as FireFox) you will see the output of date.toISOString(), which shows the UTC date and time in ISO-8601 format.
There's no spec about which to show, so either would be valid. If you want to see specific output, don't just log a Date object, call a function on the object that returns a string and log that instead.
I want to convert date string to Date by javascript, use this code:
var date = new Date('2013-02-27T17:00:00');
alert(date);
'2013-02-27T17:00:00' is UTC time in JSON object from server.
But the result of above code is different between Firefox and Chrome:
Firefox returns:
Wed Feb 27 2013 17:00:00 GMT+0700 (SE Asia Standard Time)
Chrome returns:
Thu Feb 28 2013 00:00:00 GMT+0700 (SE Asia Standard Time)
It's different 1 day, the correct result I would expect is the result from Chrome.
Demo code: http://jsfiddle.net/xHtqa/2/
How can I fix this problem to get the same result from both?
The correct format for UTC would be 2013-02-27T17:00:00Z (Z is for Zulu Time). Append Z if not present to get correct UTC datetime string.
Yeah, unfortunately the date-parsing algorithms are implementation-dependent. From the specification of Date.parse (which is used by new Date):
The String may be interpreted as a local time, a UTC time, or a time in some other time zone, depending on the contents of the String. The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
To make the Date constructor not (maybe) use the local timezone, use a datetime string with timezone information, e.g. "2013-02-27T17:00:00Z". However, it is hard to find a format that is reliable parsed by every browser - the ISO format is not recognised by IE<8 (see JavaScript: Which browsers support parsing of ISO-8601 Date String with Date.parse). Better, use a unix timestamp, i.e. milliseconds since unix epoch, or use a regular expression to break the string down in its parts and then feed those into Date.UTC.
I found one thing here. It seems the native Firefox Inspector Console might have a bug:
If I run "new Date()" in the native Inspector, it shows a date with wrong timezone, GMT locale, but running the same command in the Firebug Extension Console, the date shown uses my correct timezone (GMT-3:00).
Noticed that FireFox wasn't returning the same result as Chrome. Looks like the format you use in kendo.toString for date makes a difference.
The last console result is what I needed:
Try using moment.js. It goes very well and in similar fashion with all the browsers. comes with many formatting options. use moment('date').format("") instead of New Date('date')