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

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 U.S 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 U.S might be set her machine to use 12 hour time format and doesn’t want 12 hour clock.



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.


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

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

  1. 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");
            //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 = ""+pos.coords.latitude+"&lon="+pos.coords.longitude+"&addressdetails=1&accept-language=en_US&json_callback=chromeClockCallBack";
    			var script = document.createElement('script');
    			script.src = url;
    			//no access to location
    		  enableHighAccuracy: true,
    		  timeout: 5000,
    		  maximumAge: 0
    	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");
    			alert("24 hour clock");
  2. 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:


    Here are a few experiments with date:

    $ date +%X
    05:23:32 PM
    $ LANG=en_GB date +%X
    $ LC_TIME=en_GB date +%X

    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.

  3. 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.

  4. 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)

  5. 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
  6. 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;
  7. 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/);

Leave a Comment