I understood the javascript method toLocaleDateString() used computer settings.
Let's take the W3Schools example :
when i change date and hour formats of my computer, the result is different in Firefox or IE (as expected), but Chrome still shows the same date format, why?
From the MDN:
"The exact format depends on the platform, locale and user's settings."
And,
"You shouldn't use this method in contexts where you rely on a particular format or locale."
Basically, "Why" is because that's how Chrome does it. If you need a specific format, you're going to have to specify it yourself.
From the EMCAScript 5 standard:
15.9.5.6 Date.prototype.toLocaleDateString ( )
This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the “date” portion of the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment’s current locale.
Chrome can represent the date as a locale date string in whatever manner it likes. The standard only supplies guidelines; it does not mandate a particular format. And, in fact, the result will vary not only between browsers but also within Chrome itself depending on your locale settings.
It looks like Chrome does not use the Windows regional settings, but its own settings instead. These are available via Settings > Advanced Settings > Language. However the date format is not explicitly defined, it is inferred from the language + country choice, for instance:
English (US) sets date format to mm/dd/yyyy
English (UK) sets date format to dd/mm/yyyy
(For anyone trying to change these, don't forget - like I did - to restart Chrome for the settings to take effect)
Back to the original question, it looks like it was legit to use toLocaleDateString() as long as the idea is to present the information in a format the human user understands. But this would be an ideal world, where every user has his/her browser properly configured. Instead, Chrome is set by default to English(US) as long as people leave it be in English, and it takes some googling (which most users won't do) to change these settings.
This makes it risky to use toLocaleDateString() even when not "relying on a particular format or locale". It looks like the only "serious" option for any cross-browser web application is to manage its own date format preferences (per user, of course...)
Related
I need to convert a timestamp into human readable format. I'd like the resulting human readable format to be the users location (not the computer I deployed my code to).
I currently have this:
let d = 1662835646;
new Date(d * 1000).toLocaleString()
Which gives me this:
9/10/2022, 2:47:26 PM
Which is correct for my timezone (EST) but I don't have a way to test this for other timezones.
Basically all I'm asking is, will the above code work to where a user could be anywhere else in the world and it will show the correct date relevant to THEIR location.
Basically all I'm asking is, will the above code work to where a user could be anywhere else in the world and it will show the correct date relevant to THEIR location.
Yes, by default, the default locale and time zone are that of where the code is executing - not where it is hosted. This is true at least for browser-based JavaScript, that means it will be that of the user. For server-based JavaScript (Node.js, etc.), it will be that of the server, because that's what's executing the code.
... I don't have a way to test this for other timezones.
Yes you do. You can change your computer's time zone and locale (language) settings and restart your browser.
Alternatively, if you're using a Chromium based browser like Google Chrome or Microsoft Edge, you can change the location in the Sensors area in the dev tools. Each location can be customized for locale and time zone.
Function toLocaleString can take two params: locales & options
You can set locale to a certain locale and with the options parameter, you can set timezone and many other options to format the date.
Check the following link to see all the options available
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#options
I read in the MDN documentation that:
toLocaleTimeString() without arguments depends on the
implementation,the default locale, and the default time zone
What does this mean exactly?
And I tried the following code in both Chrome(Version 87.0.4280.88) and Safari browser(Version 14.0).
new Date().toLocaleTimeString()
in Chrome it gives output as
16:57:37
whereas in Safari it gives output as
4:57:37 PM
With regards to the above example can someone explain how the implementation is changing from one browser to another, and why is it so?
Edit:
All this was done using MAC, I tried changing preferred language under Setting -> "Language and Region" to English(US) it was English(India) before, as soon as I did that change and restarted chrome the result became.
4:57:37 PM
But for Safari without doing this change it was able to show in 12 hour format, what was the reason for that?
The specification for toLocaleTimeString states:
This function returns a String value. The contents of the String are implementation-defined, but are intended to represent the “time” portion of the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment's current locale.
with the definition of implementation-defined being:
An implementation-defined facility is one that defers its definition
to an external source without further qualification. This
specification does not make any recommendations for particular
behaviours, and conforming implementations are free to choose any
behaviour within the constraints put forth by this specification.
Therefore browsers are free to implement this feature as they see fit.
My computer is defined to use 24h format:
However, when I use var date = new Date("10/25/2020 19:32")
and then date.toLocaleTimeString()
I get a 12h format:
When no options are provided, the output of toLocaleString is entirely implementation dependent so may or may not use host settings, however they are almost certain to treat it as equivalent to a language of "default" with no options, i.e.
new Date().toLocaleString('default') === new Date().toLocaleString()
which returns true in every browser I tested. The important part is:
[toLocaleString is] intended to represent the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment's current locale.
Note that it should use the conventions of the locale (i.e. place or region), not the host system.
When a language and/or options are provided, the output is governed by ECMA-402 and is primarily based on the language code provided as the first argument (misnamed "locale"). Options also affect the output, however the host settings are not used other than to obtain the language code to use in the case of "default" for the first argument.
The underlying principle of the toLocale methods is that appropriate formatting can be determined from a language and other fairly vague options. Implementation developers then work out what format to use for each language and option combination. Clearly the host system settings can't be used when language or options are provided as that defeats the entire purpose of the function.
Your assumption that the browser will use the settings in the operating system is probably wrong.
You leave it to the browser to choose a locale for you.
My guess is that it is based on window.navigator.languages. This could be "en-US" in your case, hence the 12h format.
I reside in Canada, where we format our dates dd/mm/yyyy. I'm seeing something unusual when I'm calling toLocaleDateString()
HTML:
<input type="date" value="2016-01-13">
<p id="container">
</p>
JS:
var d = new Date("2016-01-13");
document.getElementById('container').innerText = d.toLocaleDateString();
The value of the date input is what I would expect - 2016-01-13.
The value of the paragraph is the American format - 12-01-2016 (the change in day is due to localizing from GMT to EST)
Chrome language is set to Canadian, as is my system setting (Windows 7). The date input seems to be respecting that, but I thought toLocaleDateString() would pick up Canada as my locale and format the date appropriately.
MSDN describes this function like this:
dateObj.toLocaleDateString( [locales][, options])
locales (Optional). An array of locale strings that contain one or more language or locale tags. If you include more than one locale string, list them in descending order of priority so that the first entry is the preferred locale. If you omit this parameter, the default locale of the JavaScript runtime is used.
Is the JavaScript runtime default locale something the user can change? I'm guessing not given my lack of success.
The different formatting between the date input and toLocaleDateString is quite baffling to me, any thoughts on how I can align the two?
http://jsfiddle.net/DfkU5/283/
Is the JavaScript runtime default locale something the user can change?
That depends entirely on the browser developers, they can do whatever they like. However, they tend to use system settings, but not always. Chrome ignores my settings for toLocalString, showing dates in m/d/y format when my preference is for d/m/y.
Safari, Chrome and Firefox all show a different string for toLocaleDate, which makes it just about useless.
The different formatting between the date input and toLocaleDateString is quite baffling to me, any thoughts on how I can align the two?
By far the best solution is to present dates in an unambiguous format, the easiest being to use the month name. All the following are unambiguous and easy to read:
19-Mar-2016
March 19, 2016
19 March, 2016
To do that you can write your own formatter (maybe 10 lines of code), or perhaps use a library.
In regard to input type date, not all browsers support it and there are lots of issues, so if you're going to use it you must check for support (fairly trivial) and if lacking, provide a fallback that does something sensible. And once you have a good fallback, you might as well implement it everywhere and forget input type date.
Then all the issues associated with it are gone. ;-)
Pass your locale as an arugment to toLocaleDateString()
e.g:
date.toLocaleDateString('en-CA')
or if you want to specify some fallback language, do this
date.toLocaleDateString(['en-CA','en-US'])
Check here
Hmmm... Okay so I've been searching the web for 2 days now without any luck. I've seen a lot of answers on how to format a javascript date for example new Date().toString("yyyy-MM-dd")... Which would return something like 2013-04-05.
This is absolutely not the problem.
What I want, is the possibility to set the format in which my OS displays dates, then retrieve that specific format and display it in the browser.
For example, let's say I changed the format of the date in my OS to MM-yyyy/dd (this is for arguement sakes, whether that would work or not is irrelevant)). Then I'd expect to see 04-2013/05 in my OS, right? Next I want to retrieve this specific format in my browser via Javascript so that I can use this to format my dates throughout my webpage.
If this is lunacy and cannot be done, please tell me, as I've got a headache from searching.
Also, if you say use someDateObject.toLocaleDateString() without explaining exactly why .toLocaleDateString would work, I'm going to ignore it, because I've tried setting my date-format in my OS to numerous formats and every single time I use .toLocaleDateString(), I receive the same format: dd/MM/yyyy
first attribute of .toLocaleDateString method locale(s) used.
current locale you can obtain through navigator.language (in firefox or chrome) parameter.
in IE you can obtain navigator.browserLanguage or navigator.systemLanguage
in browsers other than IE it is impossible to obtain system language this way
after this you can call new Date.toLocaleString(navigator.language||navigator.browserLanguage) and it will be formated correctly depending on browser language