One way to do that is to parse new Date().toLocaleString()
.
But this doesn't work in chromium/webkit since the string it returns isn't dependent of the user's locale (see bug report at http://code.google.com/p/chromium/issues/detail?id=3607)
I emphasize that I'm looking for a solution that is client side only and that works in chromium.
Parse
(new Date).toLocaleString()
for all browsers except Chrome, and checknavigator.language
against a map of locales and their time formats for Chrome.You should never search for local pattern this way.
toLocaleString()
is clearly a mistake (derived from Java) and should not be used. As you mentioned, this method is not well supported in various browsers (Chrome is just one of them).In fact the only web browser (from popular ones) which get it about right (but not 100% right) is IE.
To correctly format date depending on Locale, please use Globalize. It contains localized patterns dumped out of .Net.
You may alternatively want to use Dojo which also allows Locale-aware formatting, but based on CLDR.
Edit, new facts exist
There is a new standard for I18n in JavaScript - ECMA-402. This standard in fact allows for using JS
Date
's object. However, one should always pass a language tag:The only problem with this is, the only web browser I am aware of that currently implements ECMA-402 is Google Chrome.
For now it seems that still the way to go is to use something along the lines of iLib.
I know it would be the least favoured way of doing it, but could you not just check the time?
If the time is before 12, set the time to 1pm and test if the output is 13 or 1.
I know its a shoehorn of an idea, but if placed into a nice Date.prototype.is24hour(), returns true; It could work nicely?
I use http://www.datejs.com/ with dates. tends to do everything I need! So you could use that alongside a custom prototype function, and that would give you what you need!
As long as Chromium doesn't fix
toLocaleString()
there is no way to do that in chromium.For Firefox and IE parsing
toLocaleString()
will give that information.EDIT
Apparently
toLocalString()
is now fixed in Chrome. The parsing oftoLocaleString()
is therefore a solution.