I am getting an odd difference between Firefox and Chrome using the same bit of code:
var d = new Date('2019', '4', '4');
In Chrome I get the expected result: May 04 2019
In Firefox I get the following result: 2019-05-03
Why is Firefox 1 day out?
Here are some screenshots from the consoles in both browsers:
Chrome:
Firefox:
Those are the same date/time. The difference is that the first one is being shown to you in BST (British Summer Time, GMT+0100), and the second one is being shown to you in GMT (the Z on the end tells you that).
The Date constructor constructs dates in local time, which for you apparently is currently BST (for me, too :-) ). Since you haven't specified a time, it defaults to midnight. Firefox just shows you that in GMT, which is an hour earlier than midnight BST, hence the previous day.
Side note: The arguments you provide to new Date should be numbers, not strings. Although the date constructor will coerce for you, it's best practice not to rely on it.
Related
It looks like Safari's implementation of Int.DateTimeFormat assumes that the second Sunday in March will ALWAYS be the DST time cutoff which is not correct as prior to 2007 it was the first Sunday in April. It also appears that this affects the other end as well when DST ends. PS: This code is being run in Indiana, USA which is in the eastern time zone (GMT-4)
More specifically...
2007 and newer: correctly for all dates.
2006: incorrectly for dates between the second Sunday in March and first Sunday in April, and between the last Sunday in October and the first Sunday in November.
2005 and older: incorrectly for all dates between the second Sunday in March and first Sunday in November.
Here's a little JSBin that outlines the exact dates where this becomes an issue (note it all works correctly on every browser but safari)
https://jsbin.com/mayadehowu/edit?js,output
var formatter = new Intl.DateTimeFormat('en');
var date = new Date('6/2/2005');
console.log(formatter.format(date)); // => outputs "6/1/2005"
I dug in further and it may be due to this change in the ECMA specifications.
ES5.1 https://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.8 "whether daylight saving time would have been in effect if the current daylight saving time algorithm had been used at the time"
ES6 https://www.ecma-international.org/ecma-262/6.0/#sec-daylight-saving-time-adjustment "An implementation of ECMAScript is expected to make its best effort to determine the local daylight saving time adjustment. NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database"
Has anyone else encountered this problem? If so what were your solutions to work around this? I need a fix, but I am skeptical to patch over a safari-specific bug by adding an hour in specific cases because if Safari fixes this then our logic will be broken again.
This was finally fixed in Safari 14.1 per #NathanQ's comment
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')
I am working on a project which need to deal with a lot of "dates". I notice that sometimes javascript behaves differently in different browsers:
code:
new Date("Mar 30, 2017".replace(',', '').replace(/ /g, '/'))
I know I don't need to use replace to create date, but this code gives me interesting different result from Chrome and Safari.
While I run:
"Mar 30, 2017".replace(',', '').replace(/ /g, '/')
Both Chrome and Safari will gives me: "Mar/30/2017". But when I try to turn the result into a Date object, the interesting result will be:
Chrome: Thu Mar 30 2017 00:00:00 GMT-0700 (PDT)
Firefox: Date 2017-03-30T07:00:00.000Z
Safari: Invalid Date
I have already checked Javascript version of both browsers, and they are using the same version (1.7). Can anyone explain why Chrome behaves differently than Safari in this regard?
UPDATE
I know "Mar/30/2017" is not a valid Date format. But my question is why javascript behaves differently in different browsers. For those answers complaining about my Date format. Please read the question before answer it. I will take #Felix Kling 's answer, and thanks for all answers all the same.
Can anyone explain why Chrome behaves differently than Safari in this regard?
The specification says that handling unknown date formats is implementation dependent:
[...] 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 (including extended years) called out in Date Time String Format (20.3.1.16). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats. [...]
Safari and Chrome use different JavaScript engines and therefore their behavior can (and do) differ in this case.
new Date
when I use the date function in chrome I get something like this
Thu Jul 16 2015 20:37:47 GMT-0700 (Pacific Daylight Time)
when I do the same function in firefox I get this
2015-07-17T03:29:03.110Z
why are they different? I googled for a bit and search on stack but even the examples they were using to show their problem were comparing two dates of the same format. What I'd really like to know is why are they different now and how can I go about making them the chrome format cross as many browsers as possible?
Thanks
Resolved with moment.js
Firefox is in fact giving a different date string, and not simply displaying is differently as stated by Xufox.
The function I am going to use is
moment(new Date()).format("YYYY MMM D H:mm:ss")
but I will change around the .format, just wanted to get the answer here in case others run into the same problem
EDIT!!!!:
Xufox was right. I was a dummy. I had to manually edit some code in my timeline feed to get it going. I needed to use Date.parse on my generic time string, do my editing to the time, then use new Date. Thanks Xufox.
Am seeking confirmation if this is a bona fide documentation and/or implementation bug with Javascript's Date.parse method.
The docs I'm referring to are at https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse and they say 'If you do not specify a time zone, the local time zone is assumed.'
But the following code shows that, despite not specifying a time zone, local time is not being assumed (but rather my timezone offset is being applied), if the string passed to Date.parse begins with the 4-digit year representation, and is dash-delimited.
var euroStyleDate = '2011-10-04';
var amerStyleDate = '10/04/2011';
var euroStyleParsed = Date.parse(euroStyleDate);
var amerStyleParsed = Date.parse(amerStyleDate);
console.log(euroStyleParsed); //1317686400000
console.log(amerStyleParsed); //1317700800000
console.log(new Date(euroStyleParsed));
//Date {Mon Oct 03 2011 20:00:00 GMT-0400 (Eastern Daylight Time)}
console.log(new Date(amerStyleParsed));
//Date {Tue Oct 04 2011 00:00:00 GMT-0400 (Eastern Daylight Time)}
There may even be other cases, and I'm sure I'm not the first to discover this if I am incorrect. So beyond confirmation, I'd surely love to be pointed at more in-depth information on this if anybody knows of pertinent links.
I'm experiencing this in FF3, Chrome for Windows and of course just to be special IE8 doesn't even seem to able to perform the conversion on 2011-10-04 whatsoever: I'm just getting an empty string in my application
Thanks in advance for any further insight or resources.
I ran into this concept, too. For anyone googling "Javascript dates dashes slashes" like I was, this is the clearest demonstration that I can think of as to what's going on here.
In short, slashes means local time zone, and dashes means UTC. Other answers has explanations regarding why.
<script type="text/javascript">
var
testB = new Date("2012/02/09"),
testC = new Date("2012-02-09");
alert(testB.toString());
alert(testC.toString());
alert(testC.toUTCString());
</script>
**Update:**It looks like there are several different standards at work here:
The EMCAScript < 5 standard allowed for dates in the standard IETF format, e.g. Sun Oct 03 2010. With these dates, the local timezone is assumed.
In ECMAScript 5, a limited version of the ISO 8601 standard is also allowed, e.g. 2010-10-03. The spec seems to say (perhaps following ISO 8601?) that in this case, the UTC timezone is assumed if one is not specified.
I haven't found a spec that says Date.parse can handle mm/dd/yyyy dates, but my browser (Chrome 14) clearly can, and probably other browsers can too. This appears to follow standard 1 above, assuming the local timezone. Given that it's not in the spec, however, I would recommend not using this version, as it's likely to be browser-dependent (and I have no idea whether 10-03-2010 would result in a different date if I had a European locale set on my browser).
There are a few issues with the native Date.parse function in most interpreters - I have often had timezone issues like the one you describe. So in general, I either use a library like Datejs or I write my own parsing functions. The DateTime module of the SIMILE AJAX library has a pretty good example function for parsing ISO-8601 dates (what you're referring to as euroStyleDate, plus an optional time component).
When setting dates, I generally use new Date() and then use the setUTC*() functions to set the different date elements to my desired precision. It's not perfect, but at least you're dealing with a clear timezone.