I am facing an issue in converting datetime in current timzone.
I am receiving this date string from server in a format "2015-10-09T08:00:00" which is Central Time but when I convert this date time using new Date(strDate) in GMT+5 its returning me below which is incorrect.
var dateObj = '2015-10-09T08:00:00';
new Date(dateObj); // return me below
Fri Oct 09 2015 13:00:00 GMT+0500 (PKT)
Another way I used is to convert by adding timezone offset and its returning me right result but defiantly failed when daylight saving activated.
dateObj2 = '2015-10-09T08:00:00'+'-06:00';
new Date(dateObj2)// return me below
Fri Oct 09 2015 19:00:00 GMT+0500 (PKT)
I appreciated if anyone help OR suggest me efficient way to handle to timezone conversion with daylight saving in JavaScript?
Thank you.
Note that behavior of the code you wrote differs between the browsers:
new Date('2015-10-09T08:00:00').toString()
// "Fri Oct 09 2015 10:00:00 GMT+0200 (Romance Daylight Time)" // Chrome 46 on Windows 8.1
// "Fri Oct 09 2015 08:00:00 GMT+0200 (Romance Daylight Time)" // Firefox 41 on Windows 8.1
// "Fri Oct 09 2015 08:00:00 GMT+0200 (Romance Daylight Time)" // IE11 on Windows 8.1
// "Fri Oct 9 08:00:00 UTC+0200 2015" // IE10 emulation
// "Fri Oct 9 10:00:00 UTC+0200 2015" // IE9 emulation
// on IE8 it even returns NaN!
(my timezone is Paris)
So, Firefox and IE interpret the provided date as specified as if it were in local timezone of the user, whereas Chrome interprets it as UTC, and when printed, it gets converted to user's timezone.
Checking the MDN docs, this is due to differences in EcmaScript 5 and EcmaScript 6 (2015) specifications. It seems that Chrome follows ES5 spec while Firefox and IE11 follow ES6 spec.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#ECMAScript_5_ISO-8601_format_support (emphasis mine)
The date time string may be in ISO 8601 format. For example,
"2011-10-10" (just date) or "2011-10-10T14:48:00" (date and time) can
be passed and parsed. The UTC time zone is used to interpret arguments
in ISO 8601 format that do not contain time zone information (note
that ECMAScript 2015 specifies that date time strings without a time
zone are to be treated as local, not UTC).
Unfortunately Date object in JavaScript is famous for its quirks and cross-browser inconsistencies, particularly on ambiguous input.
I wrote here
how you can leverage moment.js or native Intl API to make sure your date will not be converted to user's timezone (the secret is to use UTC manipulating methods).
In general it's best to always specify either both time and UTC offset, or just a UTC timestamp, to make sure your input is unambiguous.
Coming back to your example, you can use following code:
moment('2015-10-09T08:00:00-06:00')
.utcOffset(+300).locale('en_gb').format("LLLL")
// "Friday, 9 October 2015 19:00" cross-browser
in which you say "this is date in UTC-0600, please convert and print it as UTC+0500 (+300 minutes)". Then you can pass in which locale you want it printed (i.e. language + culture specific settings, e.g. en_gb uses 24 hour clock while en_us 12-hour clock) and use multitude of date formats supported by moment.js.
Related
This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 3 years ago.
new Date('yyyy-mm-dd') sets timezone to local timezone but
new Date('yyyyy-mm-dd') sets timezone to GMT
new Date("2019-05-29")
Wed May 29 2019 05:30:00 GMT+0530 (India Standard Time)
new Date("11111-05-29")
Mon May 29 11111 00:00:00 GMT+0530 (India Standard Time)
Why does this behavior occur
Your first one is creating a UTC date but you're displaying it in your local timezone. From the documentation...
Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local
Your second date is being created in your local timezone. The reason for this is because the ISO 8601 standard only supports a 4-digit year (by default), therefore it does not qualify for the above condition.
In javascript, I have a date in UTC, and I want to stringify it and parse it but maintain it's UTC. I did this code
var f = { f : new Date("Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time)")}
undefined
JSON.stringify(f)
"{"f":"2019-05-28T00:11:13.000Z"}"
JSON.parse(JSON.stringify(f))
{f: "2019-05-28T00:11:13.000Z"}
You can see that after I stringified it, it changed to the next day. And then when I parse it, it kept it as a string and even of the next day. I want it so that after I parse it, I get back the Date object of Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time).
Does anyone know what's wrong?
Thanks
You can see that after I stringified it, it changed to the next day
No, it didn't. "Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time)" was parsed to a time value of 1559002273000, which defines a moment in time that is that many milliseconds after 1970-01-01T00:00:00Z. It's equivalent to 2019-05-28T00:11:13.000Z (and other timestamps in other time zones). E.g. on a system set to an eastern Australian timezone you'd get "Tue May 28 2019 10:11:13 GMT+1000 (AEST)".
I want it so that after I parse it, I get back the Date object of Mon May 27 2019 20:11:13 GMT-0400 (Eastern Daylight Time)
The date object has no knowledge of the timezone of the original timestamp, it just stores the time value. The string produced by toString just uses the host system timezone setting to generate a "local" timestamp in the format specified by ECMA-262. Note that the timezone name is implementation dependent and since they aren't standardised, the names and abbreviations differ between implementations. E.g. Safari shows "AEST" and Firefox "Australian Eastern Standard Time".
You can use toLocaleString to generate timestamps for different timezones, but the date object doesn't know what the original timezone was and the format may not be what you want.
Also, toLocaleString uses IANA timezone identifiers (e.g. Africa/Kinshasa), which relate to geographic locations that are used to deduce the applicable timezone rather than common names like "Eastern Daylight Time" which are not standardised and can be ambiguous or obscure. The IANA designators mean things like daylight saving and historic timezone offset changes can be applied more easily than with other designators.
For my WebApp I'm writting unit-tests using Jest and my dev environment is IntelliJ Ultimate 2018.1.
In my unit-tests I need to create Date() from a String. My problem is that when I share this unit-test with my colleague it's not working because the Date(String) is returning a different date (he's using the same dev environment).
For example, In my evironment, when I execute new Date("2018-05-12T19:00:00") I get Sat May 12 2018 19:00:00 GMT+0200 (Romance Summer time)
When my colleague executes exactly the same line of code, he gets Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
When I add a Z at the end of the date, like new Date("2018-05-12T19:00:00Z") I get Sat May 12 2018 21:00:00 GMT+0200 (Romance Summer time) and he gets the same date with Sat May 12 2018 21:00:00 GMT+0200 (Paris, Madrid (heure d'été))
Why do we get this 2 hours differences when using new Date("2018-05-12T19:00:00") ? We are on the same timezone.
Thanks for your help!
The older ECMAScript 5.1 Spec says in §15.9.1.15:
... The value of an absent time zone offset is "Z".
That means, if you don't specify an offset, it will assume you meant UTC.
Note that since this is the opposite of what ISO-8601 says, this is behavior has been changed in ECMAScript 2015 (6.0), which says in §20.3.1.16:
... If the time zone offset is absent, the date-time is interpreted as a local time.
Thus, it would seem that your colleague is executing the code through an older version of the JavaScript engine. Your string is being interpreted as local time per the newer spec, and theirs is being interpreted as UTC per the older spec. Since you said this is all through Node.js, they should simply upgrade to a newer version of Node.js.
I blogged about this behavior some time ago, if you'd like more details.
If you want to be resilient to older environments, consider parsing the date string yourself or with a library. There are many to choose from. In general, many people do not trust the string parser that comes attached to the Date object because it has changed over the years, has some implementation-specific behaviors, and still does silly things like assuming whole dates like "2018-07-26" should be interpreted as UTC instead of local time like ISO 8601 specifies.
I'm using ASP.NET MVC 3 with the default Json serializer (not Json.NET implemented in MVC4+) and dates from my JsonResults come back looking like /Date(-105998400000)/. I am parsing the number out and newing up a Date with this value, but I get inconsistent results between IE and Chrome.
var date = new Date(-105998400000);
See my jsfiddle in various browsers. My results are:
IE10 - Mon Aug 22 23:00:00 EST 1966
Firefox - Tue Aug 23 1966 00:00:00 GMT-0400 (US Eastern Standard Time)
Chrome - Tue Aug 23 1966 00:00:00 GMT-0400 (US Eastern Daylight Time)
Two of my clients are seeing the August 22 date in Chrome.
Why does a new Date return different values in different browsers with the UTC milliseconds value?
My original implemented answer to this issue is here, using ISO 8601 dates from the Json.NET serializer instead of UTC millisecond offsets from the legacy ASP.NET MVC3 Json serializer.
I did get some insight with this odd outcome thanks to user dandavis.
var date = new Date(1257397200000);
document.write(date);
Ran the code above I got Wed Nov 04 2009 23:00:00 GMT-0600 (Central Standard Time)
I am looking for a way to create date object based on different time zone, say for that time stamp I want to obtain date object like Thursday, November 5th 2009, 00:00:00 (GMT -5).
Note that the dates are different according to above two time zones, though they represent same point in time. I am in CST, is that why the created object is generated using CST?
Thank you.
No, these dates aren't different as they don't represent different point in time. The both represent Thu, 05 Nov 2009 05:00:00 GMT.
Date object in JavaScript is time-zone independent, it only represents point in time. The fact that Date.toString() includes time zone is very misleading, there is no time-zone information in Date. It is only a wrapper around milliseconds since epoch.
The time zone you see is based on OS/browser locale. You cannot create Date object in different time-zone. Consider using getUTC*() family of methods to get browser time-zone agnostic values.
BTW your example code prints:
Thu Nov 05 2009 06:00:00 GMT+0100 (CET)
on my computer - and this is still the same point in time.
See also
Annoying javascript timezone adjustment issue