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')
Related
My local machine in EST timezone.
I'm trying to convert date string to date object in js but getting an day before from date string in date object.
new Date('2020-04-03') for this i'm getting Thu Apr 02 2020 20:00:00 GMT-0400 (Eastern Daylight Time) this output.
new Date('2020/04/03') for this i'm getting Fri Apr 03 2020 00:00:00 GMT-0400 (Eastern Daylight Time) this output.
console.log(new Date('2020-04-03'))
console.log(new Date('2020/04/03'))
I don't know what is the difference between these can anyone explain that?
How i fix this issue?
The reason why the two date parsings give you different results is because it's triggering two different date handling modes.
In one case, 2020-04-03, it's treating the date as an simplified version of ISO 8601 format, for which JavaScript creates a date in the UTC time zone if no time zone is specified.
The second date, 2020/04/03, is not in an officially supported format, so JavaScript falls back to an implementation-specific parsing of the date, so it may not even be consistent across browsers. In that case, it's choosing to use your local time zone.
The MDN article on Date.parse() offers a detailed explanation of how date parsing works in the JavaScript standard and how non-standard behaviors exist among browsers in some cases.
In short, it's a good idea to stick with ISO 8601 dates whenever possible, not only because JavaScript handles them in a consistent way, but they're also easily sorted, and they're widely supported across many programming systems.
Try new Date('2020-04-03 00:00:00')
By default, the date string is parsed in UTC timezone. When you output a date, by default it converts it to your local timezone set by your browser.
To solve, you can enter your date as the UTC equivalent, or simply do as the others have stated here and include the timezone in your date string
let date = new Date('2020-04-03 EST');
I'm pulling dates from a SQL database which treats them as dates that start at midnight. When I go to use toLocaleDateString() on them, it formats them properly, however not before losing a day.
Before formatting: 2011-09-01T00:00:00
After formatting: 8/31/2011
Code:
plan.dateReceived = new Date(plan.dateReceived).toLocaleDateString()+','+plan.dateReceived;
Why does it do this, and what inline fix can I make to have it behave properly?
I also found another post that had a similar problem, but I'm not 100% convinced that it's a timezone issue.
If you run the code in pieces, you'll notice that new Date('2011-09-01T00:00:00') produces output like Wed Aug 31 2011 20:00:00 GMT-0400 (EDT) (my computer is in EDT right now).
This is because (doc):
Differences in assumed time zone
Given a date string of "March 7, 2014", parse() assumes a local time
zone, but given an ISO format such as "2014-03-07" it will assume a
time zone of UTC. Therefore Date objects produced using those strings
will represent different moments in time unless the system is set with
a local time zone of UTC. This means that two date strings that appear
equivalent may result in two different values depending on the format
of the string that is being converted (this behavior is changed in
ECMAScript ed 6 so that both will be treated as local).
Converting that to the locale date string will convert it to a string appropriate for the browser's locale. Documentation indicates that "the default is the runtime's default time zone".
If you want to ensure the string is in UTC time, use
new Date('2011-09-01T00:00:00').toLocaleDateString('en-US', {timeZone: 'UTC'})
We experienced this problem on Google Chrome v87.0.4280 IOS, but not on a computer with the same browser.
The problem was that the timezone string did not contain a Z at the end.
"Z" is kind of a unique case for DateTimes. The literal "Z" is
actually part of the ISO 8601 datetime standard for UTC times. When
"Z" (Zulu) is tacked on the end of a time, it indicates that that time
is UTC, so really the literal Z is part of the time.
Appending Z to the datetime fixed the problem.
new Date('2011-09-01T00:00:00Z').toLocaleDateString('en-US', {timeZone: 'UTC'})
I'm pulling dates from a SQL database which treats them as dates that start at midnight. When I go to use toLocaleDateString() on them, it formats them properly, however not before losing a day.
Before formatting: 2011-09-01T00:00:00
After formatting: 8/31/2011
Code:
plan.dateReceived = new Date(plan.dateReceived).toLocaleDateString()+','+plan.dateReceived;
Why does it do this, and what inline fix can I make to have it behave properly?
I also found another post that had a similar problem, but I'm not 100% convinced that it's a timezone issue.
If you run the code in pieces, you'll notice that new Date('2011-09-01T00:00:00') produces output like Wed Aug 31 2011 20:00:00 GMT-0400 (EDT) (my computer is in EDT right now).
This is because (doc):
Differences in assumed time zone
Given a date string of "March 7, 2014", parse() assumes a local time
zone, but given an ISO format such as "2014-03-07" it will assume a
time zone of UTC. Therefore Date objects produced using those strings
will represent different moments in time unless the system is set with
a local time zone of UTC. This means that two date strings that appear
equivalent may result in two different values depending on the format
of the string that is being converted (this behavior is changed in
ECMAScript ed 6 so that both will be treated as local).
Converting that to the locale date string will convert it to a string appropriate for the browser's locale. Documentation indicates that "the default is the runtime's default time zone".
If you want to ensure the string is in UTC time, use
new Date('2011-09-01T00:00:00').toLocaleDateString('en-US', {timeZone: 'UTC'})
We experienced this problem on Google Chrome v87.0.4280 IOS, but not on a computer with the same browser.
The problem was that the timezone string did not contain a Z at the end.
"Z" is kind of a unique case for DateTimes. The literal "Z" is
actually part of the ISO 8601 datetime standard for UTC times. When
"Z" (Zulu) is tacked on the end of a time, it indicates that that time
is UTC, so really the literal Z is part of the time.
Appending Z to the datetime fixed the problem.
new Date('2011-09-01T00:00:00Z').toLocaleDateString('en-US', {timeZone: 'UTC'})
This works in Chrome but not in Firefox.
new Date("2013-06-03 17:09:06-0400")
Works fine in Chrome
Gives 'NaN' in Firefox.
I would appreciate any help.
Take a look at Mozilla Developer Network's Date and Date.parse documentation.
Specifically, it states:
Alternatively, the date/time string may be in ISO 8601 format. Starting with JavaScript 1.8.5 (Firefox 4), a subset of ISO 8601 is supported. For example, "2011-10-10" (just date) or "2011-10-10T14:48:00" (date and time) can be passed and parsed.
If you throw a 'T' in between the date and the time you get:
new Date("2013-06-03T17:09:06-0400")
=> Mon Jun 03 2013 14:09:06 GMT-0700 (PDT)
In both Chrome and Mozilla, although you have to account for the the current timezone (thus PDT) of the user's system.
In my experience, the only reliable way to construct a date object from a string in JavaScript is to parse the string yourself, and then use the version of the constructor that takes a separate numeric parameter for each field.
The string-based constructor is far too prone to issues with locale-related parsing errors.
I tried this in the Chrome JS console, with my locale time zone set as PST:
(new Date("07-15-2005"))
=> Fri Jul 15 2005 00:00:00 GMT-0700 (PDT)
(new Date("07-15-2005")).getTime();
=> 1121410800000
but....
(new Date("2005-07-15"))
=> Thu Jul 14 2005 17:00:00 GMT-0700 (PDT)
(new Date("2005-07-15")).getTime();
=> 1121385600000
I was expecting string parsing to occur in both. But I can't make out why when format YYYY-MM-DD is used, it assumes a timezone offset. It's as if I'm expressing "2005-07-15" in my local TZ, but "07-15-2005" is expressed in UTC.
Is the correct explanation?
The implementation seems to be vendor specific, however looking at the documentation of date parse we see that as of 1.8.5 javascript supports both RFC2822 dates and ISO 8601 dates.
As per the Date.UTC documentation ISO 8601 dates are assumed to be in UTC time if not otherwise specified and thus the timezone difference is automatically added.
RFC2822 dates seem to be assumed as local times and as such are not modified.
I cannot seem to replicate your results, but the results seem to differ from browser to browser.
See: http://jsfiddle.net/f7DMV/
In Firefox and Opera, I get only the middle line parsing correctly, the others are Invalid Dates.
In Chrome, both the first and the second line parse correctly (and don't differ), but the last one is still Invalid.
It will vary from browser to browser. The ECMA262 spec says any string which is not in YYYY-MM-DD format and is passed to the Date function, it may fall back to implementation-specific heuristics or implementation-specific date formats.