This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 6 years ago.
In javascript I tried this
new Date(Date.parse("2016-12-15"));
And it outputs a date object but with the date as Wed Dec 14 19:00:00 EST 2016. Why is it dec 14 when I expect it as dec 15?
Thanks
JavaScript dates don't contain a time zone. The date you are parsing is interpreted as December 15, 2016 at midnight UTC.
When you are converting it back to a string, it uses the time zone from your browser locale, and since you appear to be on the american east coast, the appropriate time zone is EST.
7pm EST equals midnight the next day in UTC.
Parse is not a reliable way to parse your date...
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 (ES5 and ECMAScript 2015). Therefore Date objects
produced using those strings may represent different moments in time
depending on the version of ECMAScript supported 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.
-- Source --
I think you should get the client date with its timezone and use a library like Moment.js to parse the date correctly.
You can create a date object from a specific UTC time using .Date.UTC() method, but then you have to pass the values individually:
new Date(Date.UTC(year, month, day, hour, minute, second));
A better and safer approach would be to use moment.js
Related
Okay, newbie JavaScript question.
I am constructing a Date object from a string. This string to construct the Date is 2020-08-19T11:32:08 but the output of toISOString() is 2028-08-19T15:32:08.000Z
Why am I seeing the hour as 15 instead of 11?
2020-08-19T11:32:08 is your local time - in your timezone.
2028-08-19T15:32:08.000Z is the universal time (indicated by the Z at the end) - that's the time on the GMT/UTC. It's right in UK in winter, but otherwise the use of this is that we can all agree to use the same timezone when sharing times internationally.
If you only have local users all in the same timezone it's probably a can of worms you don't want to open. If you have international users and you want them to interact (for instance book a video meeting between New York and LA) then the convention is to use UTC dates (blame the British empire for that one).
ISO is the standard format and toISOString also uses the UTC timezone.
From MDN, emphasis mine:
The toISOString() method returns a string in simplified extended ISO format (ISO 8601), which is always 24 or 27 characters long (YYYY-MM-DDTHH:mm:ss.sssZ or ±YYYYYY-MM-DDTHH:mm:ss.sssZ, respectively). The timezone is always zero UTC offset, as denoted by the suffix "Z".
Because toISOString returns in ISO 8606 format and with UTC set to 0.
This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 5 years ago.
I have an Array with date strings formatted: "24-Jul-2017".
and when i use new Date("24-Jul-2017");
it returns date with one day offset.
2017-07-23T22:00:00.000Z
Tried different formatting but could not get correct date.
Assuming the browser is in a time zone with a UTC offset of +2 at the start of July 24th 2017, it's behaving as documented.
The Date constructor is documented as behaving like Date.parse, which then includes this documentation - along with multiple warnings not to use the constructor accepting a string, or the parse method:
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 (ES5 and ECMAScript 2015). Therefore Date objects produced using those strings may represent different moments in time depending on the version of ECMAScript supported 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.
So it's providing you July 24th 2017 at midnight in the local time zone.
It sounds to me like you'd be better off using Moment.js or something similar to give you clearer control over the parsing/formatting.
new Date(Date.UTC(year, month, day, hour, minute, second))
Try this format (UTC will be the timezone for your Date)
when i create date using date constructor new Date('2015','12'), it results in Fri Jan 01 2016 00:00:00 GMT-0500 (Eastern Standard Time). But don't it to assume that what date i am providing is already applied daylight conversion and create date object for december 2015, instead of jan 2016
When creating a date using the Date constructor, the time zone of the host system is almost always used (per ECMA-262). The only exception is when a number (interpreted as a time value, i.e. milliseconds since the ECMAScript epoch) is provided, or an ISO 8601 format string with a time zone. Even then, the internal time value of the Date (i.e. milliseconds since the epoch) is calculated in UTC and the host system time zone offset used for the non–UTC methods like getHours, getMinutes, etc.
Also, the timezone offset of the current systems settings are used for historical dates. So if the host is set for daylight saving, it will be applied to dates at times before daylight saving was implemented. Also, historical changes to daylight saving changeover dates and times (and even value) are not applied. The currents settings are assumed to always apply for past and future dates.
So all of the following will apply the timezone offset of the host system when creating a date for 3 February, 2016:
new Date('2/3/2016'); // US format is assumed by most browsers.
// May also create an invalid Date
new Date(2016, 1, 3); // months are zero indexed so 1 is February
new Date('2016-02-03T00:00:00'); // note missing time zone
However, the following will be treated as UTC (or invalid):
new Date('2016-02-03'); // contrary to ISO 8601, missing time zone for this
// format only is assumed to be UTC
new Date('2016-02-03T00:00:00Z'); // Note has a time zone of GMT
If you want to reliably create a Date for a specific instant in time from a string, you must provide a string with the time zone offset. Then parse it yourself since parsing of date strings is largely implementation dependent and varies across implementations. The best format to use is ISO 8601 extended so something like:
'2016-02-03T00:00:00-0800'
which represents the same instant in time no matter what the settings of the host system are. You just need to reliably parse it.
There are many good libraries for parsing and formatting, or you can write your own small functions for particular parse and output formats.
I am looking for a date format (only year, month and day, no time component), that will be guaranteed to be interpreted as local time, in all reasonably modern browsers, when passed to the Date() constructor in JavaScript.
The (3-letter English month abbreviation) (2-digit date) (4-digit year) format seems to work. When I do new Date('Apr 01 2015') on my English system, in Chrome, with my machine being in the Eastern timezone, I get back Wed Apr 01 2015 00:00:00 GMT-0400 (Eastern Daylight Time) which is exactly what I want.
However, I am not sure if this (3-letter English month abbreviation) (2-digit date) (4-digit year) format is guaranteed to be interpreted in the same way regardless of browser and browser/OS locale/language.
Will this format work the same way across different (reasonably modern) browsers and locales? If not, then is there some other format that will work?
Please note that ISO-8601 doesn't answer this question. ISO-8601 date-only strings are interpreted as being in UTC, and not in local time, so new Date('2015-04-01') is interpreted as Tue Mar 31 2015 20:00:00 GMT-0400 (Eastern Daylight Time), i.e. April 1 turns into March 31, which is not what I'm looking for.
I am looking for a date format (only year, month and day, no time component), that will be guaranteed to be interpreted as local time, in all reasonably modern browsers, when passed to the Date() constructor in JavaScript.
There isn't one. There are a number of formats that, in practice, are reliably parsed by all browsers in use however none of them are required by ECMA-262 to be supported by ECMAScript implementations.
There is one format, a version of ISO 8601, that is specified in ES5 and ECMAScript 2015 however dates without a time zone are to be treated as UTC in ES5 and "local" in ECMAScript 2015.
But that was seen by implementers as "breaking the web", so while some browsers implemented that for a while, they have now reverted to ES5 behaviour and treat a missing timezone as UTC.
A small change in format such as changing the separator from "-" to "/" causes a reversion to implementation dependent behaviour and may cause the date to be treated as UTC or local (though most seem to treat 2015/12/17 as local).
So if you want a guarantee, there isn't one. However, if you are prepared to write a 2 line function, you can parse an ISO 8601 like string reliably based on whatever time zone you like. If you want it to be treated as local (i.e. set to 00:00:00 and offset based on system settings), then:
function parseISOLike(s) {
var b = s.split(/\D/);
return new Date(b[0], b[1]-1, b[2])
}
document.write(parseISOLike('2015-12-17'));
will do the job (without checking for valid values) and allow the separator to be any non–digit, so 2015/12/17, 2015-12-17 and 2015.12.17 will all be correctly parsed.
Edit
Parts of the above have been edited thanks to input from Matt Johnson.
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')