js Date toLocaleString - javascript

I use the 3 browsers to output this result.
Chrome:
new Date().toLocaleString()
> "Sun Sep 04 2011 21:40:04 GMT+0800 (HKT)"
Safari:
new Date().toLocaleString()
> "2011年9月4日 下午09时54分51秒格林尼治标准时间+0800"
FF:
new Date().toLocaleString()
> "Sun Sep 4 21:46:03 2011"
why not the same output result? timezoom?

It depends on the configuration of the computer, the user's preferred date format, obviously the user's locale, and how the browser determines this.
You should really prefer using a proper date library such as datejs for formatting.
See their Date.toString() and format specifiers.

That's a bug in webkit, actually; in particular in Chrome but Safari is indeed affected too: http://code.google.com/p/chromium/issues/detail?id=3607
toLocaleString() does not translate to the locale!
The worst is, it's closed as WontFix. How is that possible? We should try and re-open it. The conclusion on the bug is that somewhen a new javascript globalization apis (that is well explained here) will appear. That doesn't sound like a solution to me!
In any case, if possible, follow #arnaud576875 suggestion to use datejs which is old but still very good.

Check this link
And this example:
var event = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
// British English uses day-month-year order and 24-hour time without AM/PM
console.log(event.toLocaleString('en-GB', { timeZone: 'UTC' }));
// expected output: 20/12/2012, 03:00:00
// Korean uses year-month-day order and 12-hour time with AM/PM
console.log(event.toLocaleString('ko-KR', { timeZone: 'UTC' }));
// expected output: 2012. 12. 20. 오전 3:00:00

Related

Convert ISO Date string to date in JavaScript

Need help to convert exactly from ISO Date string to Date:
I have an ISO string date: "2016-01-23T22:23:32.927".
But when I use new Date(dateString) to convert Date, the result is wrong:
var date = new Date("2016-01-23T22:23:32.927");
The result is: Sun Jan 24 2016 05:23:32 GMT+0700. It's not true. I want the date is 23 not 24.
Please help me. Thanks a lot!
You need to supply a timezone offset with your iso date. Since there isn't one, it assumes the date to be in GMT and when you log it out, it prints it in the timezone of your browser. I think that if you pass "2016-01-23T22:23:32.927+07:00" to new Date() you would get the value you are expecting.
JavaScript environments (browser, node,...) use a single timezone for formatting dates as strings. Usually this is your system's timezone. Based on the output you get, yours is GMT+0700.
So what happened:
The string you passed as ISO format to the Date constructor doesn't specify a timezone. In this case it is treated as UTC.
When you then output the date (I'll assume with console.log), it is converted to the timezone of your environment. In this case 7 hours where added.
If that doesn't suit you, you can change the way you output the date. This depends on what output you want, e.g.:
If you just want the UTC timezone again, you can use date.toISOString().
If you want to output it in another timezone, you can call date.getTimezoneOffset() and figure out the difference between both timezones. You'd then probably need to get the individual date parts and add/subtract the timezone difference accordingly. At this point you could consider using an existing library, taking into account their possible disadvantages.
If you're willing and able to add a dependency, I recommend using moment.js for this. It makes date handling in Javascript much more straightforward and a lot safer, and fixes your specific problem right out of the box.
To do this, 1st load it from a CDN, e.g. Moment.JS 2.14.1 minified. Then use it as follows:
var date = moment("2016-01-23T22:23:32.927");
console.log(date);
// output: Sat Jan 23 2016 22:23:32 GMT-0500
...i.e. your desired result :)
Here's a jsfiddle demonstrating this.
Use date.toUTCString()
it'll give you 23 instead of 24 as it Convert a date object to a string, according to universal time

Firefox vs Chrome Date Difference with momentJS

I have a function that gets the date in the DATETIME format:
2015-06-18 00:00:00
Doing moment.utc("2015-06-18 00:00:00").toDate() will display different results in Firefox and Chrome:
Firefox: Date 2015-06-18T00:00:00.000Z
Chrome: Thu Jun 18 2015 03:00:00 GMT+0300 (EEST)
Also, using new Date("2015-06-18 00:00:00") will return Invalid Date in Firefox, but adding a "T" before the hours will fix that issue. But then if I do new Date("2015-06-18T00:00:00") will return:
Firefox: Date 2015-06-17T21:00:00.000Z
Chrome: Thu Jun 18 2015 03:00:00 GMT+0300 (EEST)
It's driving me nuts.
How can I get both browsers to show the same hour?
How can I get Firefox to display the result in Chrome's format?
The whole point of using a dedicated date library is to obtain transparent cross-browser date features. However, as soon as you run .toDate() you get back the native Date object. If you then convert it to string by using the builtin Date.toString() method you've finally dropped all the library goodies and got back to vanilla JavaScript.
Tips:
Don't use strings expect for display purposes
Use the library features to generate those strings
try
new Date("2015-06-18T00:00:00").toString()
looks the same on both for me

IE's toLocaleString has strange characters in results

I've run into a super strange thing that apparently is IE-specific in toLocaleString on dates.
In the IE console window:
new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
"‎8‎/‎28‎/‎2014‎ ‎1‎:‎51‎:‎09‎ ‎PM"
Now, type out that string manually as a string and compare it to what the method returned:
"8/28/2014 1:51:09 PM" === new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
false
Does anyone have any idea why this is occurring in IE? This doesn't occur in Chrome.
Update: more examples:
new Date("8/28/2014 1:51:09 PM")
[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time)[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time)
new Date(new Date("2014-08-28T20:51:09.9190106Z").toLocaleString())
[date] Invalid Date[date] Invalid Date
First, a bit of background: IE11 implemented the ECMA-402 ECMAScript Internationalization API that redefined Date.prototype.toLocaleString (as well as toLocaleDateString and toLocaleTimeString) as calls to format on Intl.DateTimeFormat. As such, d.toLocaleString() is equivalent to
Intl.DateTimeFormat(undefined, {
year: 'numeric',
month: 'numeric',
day: 'numeric',
hour: 'numeric',
minute: 'numeric',
second: 'numeric'
}).format(d)
You might think that this is pretty explicit but browsers are allowed a large amount of leeway with what formats they support and what characters compose the format. This is by design - with all the locales and languages around the planet, specifying this would be quite burdensome and very difficult to keep up-to-date. For this reason you cannot expect to be able to compare the results of toLocaleString across browsers or even expect the same browser to continue giving the same result from release to release. As the underlying locale data changes (perhaps because local custom has changed, or more data is available, or better formats are added), so too will the format that is returned from this API.
The takeaway from this is that you should try not to rely on comparing the output of the toLocaleString APIs with some static value in your application. Further, given a date d, Date.parse(d.toLocaleString()) may work sometimes but not others depending on locale, so it's best to avoid this as well.
With that said, en-US is relatively stable and for the most part browsers do (for now) agree on what that basic format is. However, IE inserts bidirectional control characters around the date. This is by design so the output text will flow properly when concatenated with other text. This is especially important when mixing LTR and RTL content such as concatenating a formatted RTL date with LTR text.
Use
Str.replace(/[^ -~]/g,'')
This will remove unwanted special characters.
It turns out you can't see them, but IE's Date.toLocaleString is apparently including left-to-right marks in it (U+200E):
8<200E>/<200E>21<200E>/2014<200E> <200E> 9<200E>:<200E>16<200E>:<200E>:18<200E> <200E>AM
awesome. I guess it is time to submit a bug to IE?
Please look at http://jsbin.com/mehowehase/1/edit?html,js,console
var dt = new Date();
var x = dt.toLocaleDateString();
console.log("length : "+x.length);
var arr = x.split("/");
console.log("month : "+parseInt(arr[0],10));
In the above the length of x is 14 in IE but 9 in other browsers. This supports John's comment that IE is adding left-to-right marks. This definitely looks like a bug to me.
I don't see this in my IE11 so it could be something to do with your settings/config in IE or your machine. For me the result is:
"‎28‎/‎08‎/‎2014‎ ‎21‎:‎51‎:‎09" === new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
true
Did you copy-paste the date string passed to the constructor from a web page?
I don't think the IE team will accept it as a bug at this stage because it doesn't have clear repro steps

Javascript + Date conversion in IE8 and Safari

I am trying to convert a datetime (raw format in UTC: 2012-12-05T21:55:00) to readable local time format but the output varies across browsers:
DateTime = new Date(DateTime);
alert(DateTime);
In Chrome it appears as:
Wed Feb 20 2013
05:31:00 GMT +0800
(Malay Peninsula
Standard Time)
and in IE:
Wed Feb 20 05:31:00
UTC+0800 2013
Hence, I applied a .format to it:
DateTime = new Date(DateTime);
DateTime.format('dd MMM, yyyy hh:mm tt')
alert(DateTime);
This format appears good and consistent across Chrome and IE9:
20 Feb, 2013 05:31 AM
but there's an issue in displaying it in IE8 and Safari, it shows the date as:
NaN, 000NaN
NaN:NaN AM
I tried other JS plugins like date ninja but no help either. Can anyone advise how to go about the NaN issue? Thanks.
I faced 'exactly' the same issue you are facing a few months back. Use moment.js. It gives consistent date formats in Chrome, FF and IE(Including IE 8)

How does Date.toLocaleDateString() work?

I've to represent the date with local user's configurations. Follows the MDN description:
The toLocaleDateString method relies on the underlying operating
system in formatting dates. It converts the date to a string using the
formatting convention of the operating system where the script is
running. For example, in the United States, the month appears before
the date (04/15/98), whereas in Germany the date appears before the
month (15.04.98).
I do this:
var date = new Date ();
console.log (date.toLocaleDateString ());
It prints out Saturday, October 13, 2012 but what I expect is Sabato, 13 Ottobre, 2012 (that's the Italian date format).
Now, configurations of my browser and my system are set properly (Italian language and the above format date) so I don't understand how does toLocaleDateString work.
Am I doing it right?
According to the Mozilla documentation, the format can vary wildly depending on the user's location and computer settings.
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/toLocaleDateString
The exact format depends on the platform, locale and user's settings.
This question is out-of-date.
These are my tests:
(new Date ()).toLocaleDateString () -> "4/9/2013" (italian format 'd/m/Y') with Chrome 29
(new Date ()).toLocaleDateString () -> "mercoledì 4 settembre 2013" (italian format 'D d M Y') with Firefox 22
It works with newest browsers versions.

Categories

Resources