I need to obtain current time (from a credible source) using JSON. Precise time is mission-critical in my application so I cannot rely on the time of the device, even if it is only a second or two off.

EDIT: I am not as worried about 'precision' rather just so that several devices running the app have the same time.

I need to obtain current time (from a credible source) using JSON. Precise time is mission-critical in my application so I cannot rely on the time of the device, even if it is only a second or two off.

EDIT: I am not as worried about 'precision' rather just so that several devices running the app have the same time.

• javascript
• json
• datetime
• time

• 1 If you need it in JSON it kind of implies your app is running in a browser, in which case I'd be surprised if you could achieve timing precision within a second or two, considering all the async stuff going on. Or do you need JSON for another reason I'm missing? – antlersoft Commented Feb 28, 2012 at 17:02
• 4 Precision will be an issue anyway. An isolated request, without ping times etc, can't account for latency. – cHao Commented Feb 28, 2012 at 17:04
• It is a phonegap android app. So everything compiles to an .apk file. So it's not "really" a web app. But I basically need to get time from a centralized server and compare it to device's time - so that I can sync results from several devices by knowing what their time difference is with the centralized time. – antonpug Commented Feb 28, 2012 at 17:06
• agreed, < 1s precision is really impractical. by the time you request/retrieve, parse, and perform actions upon the time I'm sure you'll have lost your precision at least 1s. – Matt K Commented Feb 28, 2012 at 17:06
• Even if the server sends a precise time, device #1 may get it faster than device #2 because device #2 might be on a slow network connection. So I'm not sure if it's truly possible to have millisecond precision. – pimvdb Commented Feb 28, 2012 at 17:09

5 Answers 5

As of Jan. 07th 2020 http://worldtimeapi.org/ is working fine. we can get current date and time details for specfic time-zone or ip address easily in either json format or plain text format.

http://worldtimeapi.org/api/timezone/America/Santiago

the above url will give you the current date and time details in json for "America/Santiago".

http://worldtimeapi.org/api/timezone/Asia/Kolkata

the above url will give you the current date and time details in json for "Asia/Kolkata".

Request the current time based on your public IP (as JSON):

$ curl "http://worldtimeapi.org/api/ip"

Note: by default, the API returns JSON. Adding a suffix of .txt to any API URL will return a plain-text response, which may be easier to parse on some systems.

function getTime(zone, success) {
    var url = 'http://json-time.appspot.com/time.json?tz=' + zone,
        ud = 'json' + (+new Date());
    window[ud]= function(o){
        success && success(new Date(o.datetime));
    };
    document.getElementsByTagName('head')[0].appendChild((function(){
        var s = document.createElement('script');
        s.type = 'text/javascript';
        s.src = url + '&callback=' + ud;
        return s;
    })());
}

getTime('GMT', function(time){
    // This is where you do whatever you want with the time:
    alert(time);
});

from here

As of January 2025, almost none of the above API links work any longer.

As suggested before, the best choice for this kind of project would be using NTP (Network Time Protocol), which is a rock-solid Internet standard that has been around since the dawn of ages and provides ultra-accurate time with millisecond precision (some servers even guarantee nanosecond precision!), no matter how inaccurate your system's clock is (most clocks these days will be accurate within a second per day, but there might be some that don't even manage that much).

The problem for the OP is that they only have access to JavaScript. Assuming that they can, at least, retrieve some libraries from the web, one possible choice would be to use ntp-time. You just need to add a handful of NTP servers to the configuration, and your job is done. Typically, these would be configured with the world-wide pool.ntp.org (open to the whole world), or limited to specific providers, such as Cloudflare (time.cloudflare.com), which might give the fastest access world-wide, or Google (time.google.com), which should come as a very good runner-up in terms of response time. Of course, Microsoft, Apple, and a zillion others also run their own NTP time-servers, and depending on the kind of application, picking one of theirs might be better.

None of the above servers have any rate limits (which would defeat the whole purpose!) but it's advisable not to overload these public systems — they do have DDoS measures active (e.g., if you have a smartphone app distributed to millions of users, all of them requesting NTP date several times per second, you'll be surely blocked out very quickly!). NTP is meant to be used 'as needed'; after a short training period, it figures out how big the 'drift' is (how much your system's clock is accurate over time), and makes synchronisation requests 'as needed' to keep the accuracy of the clock as close as possible to 100% — therefore, even very old and unreliable system clocks will be accurate within a few seconds.

Many of the above systems, to prevent abuse, are moving to NTS (Network Time Security), which adds a level of TLS encryption with an exchange of PKI, to limit the attack surface. Again, several million apps making requests several times per second, encrypted & authenticated, will also be blocked very quickly.

Since the OP mentions in the comments that the main purpose is to check the validity of a digital certificate with extreme precision, thus needing to rely on a reasonably accurate clock, there is an interesting alternative developed by Google: it's called Roughtime, designed to be secure and reliable, but not necessarily absolutely accurate. They designed it exactly with the use-case of checking the validity of certificates installed on a Chrome (or Chromium-based) browser — they figured out that 25% of the rejected certificates were due to a badly configured clock on the user's device. Cloudflare also has adopted Google's idea and launched their own Roughtime service. Both can be used simultaneously, of course.

Roughtime is configured in a slightly different way and is meant to be used on devices that can easily maintain a perfectly accurate clock (to whatever precision it allows) for a period of, say, 10 seconds. Thus, the worst-case scenario is if there is a huge drift after those 10 seconds, and the device cannot sync again with any public Roughtime servers. Although both Cloudflare and Google are solid companies, having been around for several years, and operating a world-wide operation with hundreds of separate data centres around the world, they should be available even after 2038 (you know... after the Y2038 bug crashes all 32-bit Unix-based operating systems