如果用户的机器使用 12 小时制（上午/下午）或 24 小时制（军用时间），则使用 javascript 检测

Question

Is it possible to detect if user's machine is using 12 hour clock (am/pm) or 24 hour clock (military time)?

One way would be to check users locales, but then it is just massive list of locale comparison and someone from US who wants 12 hour clock can send me just en locale, not US_en and I have no way of knowing her preferences. At the same time someone from US might be set her machine to use 12 hour time format and doesn't want 12 hour clock.

EDIT:

date.toLocaleTimeString();

Would work it theory, as user Mouser suggested below, but unfortunately it's bugged on WebKit browsers (tested on Chrome and new Opera on Windows) and for some reason always returns am/pm time.

Example: http://jsfiddle.net/sjuaL3p4/

So I guess I have to rephrase my question if anyone has an idea how to accomplish it on webkit browsers also.

Answer 1

You can utilize the Internationalization API with resolvedOptions to determine the hourCycle :

const locale = navigator.language
Intl.DateTimeFormat(locale,  { hour: 'numeric' }).resolvedOptions().hourCycle // ?
Intl.DateTimeFormat('en-US', { hour: 'numeric' }).resolvedOptions().hourCycle // h12
Intl.DateTimeFormat('en-GB', { hour: 'numeric' }).resolvedOptions().hourCycle // h23

Answer 2

This solution works in most browsers, but bugs in Chrome.

 var date = new Date(Date.UTC(2012, 11, 12, 3, 0, 0)); var dateString = date.toLocaleTimeString(); //apparently toLocaleTimeString() has a bug in Chrome. toString() however returns 12/24 hour formats. If one of two contains AM/PM execute 12 hour coding. if (dateString.match(/am|pm/i) || date.toString().match(/am|pm/i) ) { //12 hour clock console.log("12 hour"); } else { //24 hour clock console.log("24 hour"); }

Workaround Chrome; A proof of concept

This is an ugly work-around for Chrome. It sniffs out the users country_code via reverse geolocation . That code is checked against an array with countries using the 12 hour system. This solution is ugly because you need user permission to get geolocation data and if the users locale is different it will give the wrong information, but will provide you with the country of the user. I strongly advise against using this example . It's purely for inspiration purposes. I made it up as a proof of concept.

 function getClockChrome() { navigator.geolocation.getCurrentPosition(function(pos) { var url = "http://nominatim.openstreetmap.org/reverse?format=json&lat="+pos.coords.latitude+"&lon="+pos.coords.longitude+"&addressdetails=1&accept-language=en_US&json_callback=chromeClockCallBack"; var script = document.createElement('script'); script.src = url; document.body.appendChild(script); }, function() { //no access to location }, { enableHighAccuracy: true, timeout: 5000, maximumAge: 0 } ); } getClockChrome(); var dateCountryCode = ['US', 'GB', 'PH', 'CA', 'AU', 'NZ', 'IN', 'EG', 'SA', 'CO', 'PK', 'MY']; function chromeClockCallBack(data) { //Request succeeded if (dateCountryCode.indexOf(data.address.country_code.toUpperCase()) > -1) { alert("12 hour clock"); } else { alert("24 hour clock"); } }

Answer 3

This works for all locales including ones with non-Latin number systems. Because it is that flexible, you need to know if and how you will handle that type of scenario.

This does not support IE 10 or earlier.

 function is12Hour(locale) { return !!new Intl.DateTimeFormat(locale, { hour: 'numeric' }).format(0).match(/\\s/); } console.log(is12Hour()); console.log(is12Hour('en-GB')); console.log(is12Hour('ar-SA'));

Answer 4

toLocaleTimeString should give the time in a format that reflects the user's preferences but it is unreliable.

I'm on a Debian system. The output of locale is:

LANG=en_US.utf8
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

Here are a few experiments with date :

$ date +%X
05:23:32 PM
$ LANG=en_GB date +%X
17:24:06
$ LC_TIME=en_GB date +%X
17:24:22

The %X format tells date to output the time according to the locale. The results above are exactly as expected. Setting LC_TIME is a way to change only the time format but keep everything else in the locale intact. So someone in the US could use a 24h time format even if the default for en_US is 12.

I've tried Mouser's script on my system:

$ firefox --no-remote
[Shows a time in the 12 hour format, as expected.]
$ LANG=en_GB firefox --no-remote
[Shows a time in the 24 hour format, as expected.]

So far so good. However,

$ LC_TIME=en_GB firefox --no-remote
[Shows a time in the 12 hour format, this is wrong!]

I get the same results with Chrome. It seems that both Firefox and Chrome ignore LC_TIME .

Answer 5

Besides the fact that this should never be done , .toLocaleTimeString() wouldn't be a good solution even if it did work across browsers. It returns a time string following the format set by the user's computer, but it's possible to have a 24-hour clock that still shows AM/PM, as well as a 12-hour clock that doesn't. It's not feasible to accurately or reliably detect this.

Answer 6

This simple line seems to be working for me.

var is24 = ((new Date(2014, 01, 01, 15, 0, 0, 0)).toLocaleTimeString().indexOf("15") > -1);

Though it still doesn't work in Chrome (works in IE and Firefox)

Answer 7

This works for me in Chrome. I used the selected answer from @Mouser which was not working in Chrome.

    let result = false;
    const date = new Date();
    const dateString = date.toLocaleTimeString(language, {
        timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone,
        timeStyle: 'short'
    });
    
    if (dateString.match(/am|pm/i) || date.toString().match(/am|pm/i)) {
        result = true;
    }
    else {
        result = false;
    }