Detect with javascript if user's machine is using 12 hour clock (am/pm) or 24 clock (military time)

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");
		}
	}

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

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.