Talk:TimeAPI Clock Script

Inefficient is an understatement

Attempting a GET request every second is a completely unnecessary strain on the interwebs.

At most, make a GET request every 20? seconds and update a smarter script.

P.S. When did the LSL script library get so messy?! It used to be in alphabetical order O.o

"It's a wiki" I here the multitudes moan. "Tidy it yourself!". Check the history. I did already >.<  fredgandt 09:44, 18 July 2013 (PDT)

Actually (this is so bad it played on my mind) making a GET request every 20 minutes would be excessive!

Establish an offset, and roll with it.  fredgandt 09:59, 18 July 2013 (PDT)

Free time API alternatives

All right, so you grabbed this script in order to check how accurate the LSL-reported timestamp is (for whatever reason; it's pretty accurate, actually), and, since the mentioned timeapi.org API has shut down, you need an alternative.

These days [i.e., 2025], you have three main options (and a fourth one):

1. Do a search for some of the last remaining free APIs. Be aware that those will disappear sooner or later — unless they are sponsored by a Big Company (and a long-lived one, at that), it's very likely that whoever set it up in the first place will lack the resources to keep it up all the time (pun intended). Also, it will be constantly plagued by abusers who get their kicks by bringing such systems down with crude DDoS attacks. As such, these services are seriously disappearing from the Internet-at-large; remember, you cannot monetise API calls with ads, so there is no real incentive to keep such a project available and free for all.
2. Use a limited-rate service with your own API key. This means you cannot publish your key in a public domain/open source script — or else, someone else will exhaust your allocated number of (daily) API calls. (I'm speaking from experience with some of those providers.) Such services are meant to be paid by businesses, but since developers need to do all their code testing before they sell a solution to a client, it's not unusual for many API providers to have a 'free tier'. For the purposes of using this as a proof-of-concept example, it should suffice. For a simple synchronisation system, you can rely on the built-in SL Grid clock being pretty accurate over a considerately long time period — as suggested, it would be rare to need to make any adjustments over a period of 24 hours, and that means just one call per day. Most contemporary computer clocks will, in a worse case scenario, drift up to one second a day — it's likely that LL's own grid clock is sync'ed via NTP with popular (free) NTP clients and therefore be far, far more accurate than you need (after all, the API call will not be instantaneous — you'll probably get a delay bigger than what LL's grid clock might have drifted in that day).
3. Go for a commercial service. There are plenty of those around, most are backed up by very strong and reliable companies, which use the fees to maintain their servers in good shape. Most providers will have a very low cost for their lowest tier, and possibly give you far more API calls per unit of time than you will ever need (unless, of course, you're distributing a no-perm script containing your API key and have millions of objects on the grid making one request per day... all those calls will be made on your account's credit!). Some companies offer additional tiers, 'unlimited' tiers (use it as much as you can, so long as your usage does not resemble a DDoS), or pay-per-call micropayments. It's a good idea to shop around to see what fits your requirements best. And if you have already a paid account on Google Cloud, Microsoft Azure, or similar providers, most will also have some kind of time API service available, included with your account; this is especially true for enterprise/academic/non-profit accounts.
4. (For advanced usage; not for a beginner). Host your own time server. A time server is perhaps the easiest thing you can serve via Web. Ultimately, you don't even need to return anything but a blank page; all that is needed at the API consuming end is to get the timestamp from the response. That's it. The most basic of basic webservers will do the job nicely. You can even write your own in less lines of code than what you need to write the LSL to actually make the call and parse a header from the response; in fact, I believe that in most programming languages it will just take two lines of code: attach to port 80 and respond to any request with a blank page. What can be simpler?

Well, keeping the service up, of course. If you really have a ton of scripts — say, millions — making calls to your server every day, then you need to be able to deal with the traffic spikes. These days, it almost certainly means leasing computing power from a cloud provider. Because what the 'server' needs to do is so basic and so simple, you might be able to do everything on the lowest-cost headless virtual machine; JavaScript is a popular choice for writing the code of your immensely complex, two-line code. Well, you might add another line to sync the VM's clock via NTP with third-party NTP servers — otherwise, trusting the cloud provider's clock would be meaningless in a scenario where you don't trust LL's own grid clock — which, for all purposes, also runs on a public cloud infrastructure and gets their synchronisation almost certainly from Amazon's own time servers. There are really plenty of very good alternatives offered by cloud providers for ever-decreasing costs. You're not exactly number-crunching huge databases, training your LLM AI, rendering an animation movie, or, well, mining crypto. You're just using the slimmest layer of service. The only issue, of course, is that these services are also paid — possibly more than what was described under point 3 — even though almost all cloud service provider also offer a 'free tier' for developers. The same caveats will however also apply: you'll almost certainly be able to make hundreds of thousands of calls per day within the free tier, but not millions of calls.

That said, if you're going for the 'freemium' model, I'd pick https://ipgeolocation.io/ — they do a pretty good service, you can start your development using the free tier (1000 calls per day — good enough for testing, but also important to take into account in your client's code: if you can guarantee that all your scripts will never exceed, in total, those 1000 calls per day, then you're going to be able to use it forever for free!). A reasonable alternative is to use Google's own Time Zone API, which is actually part of the Google Maps ecosystem (and requires a [free] developer account and a key with the proper credentials to access the Maps API). However, I should mention that Google's APIs — most notoriously, their key management systems and the authentication procedures — are substantially more complex than what ipgeolocation.io provides. This is mostly because everybody abuses Google's free services, if they don't take any measures to rate-limit requests (which historically they didn't bother much with). I just mention Google because, if you're a developer, it's far more likely that you already have a Google developer account than an account for ipgeolocation.io — even if you're just using the free tier — and procuring keys with the proper credentials is already second-nature for you.

My own (very) personal preferences? I'd go with Cloudflare Workers. Cloudflare has as many data centres in the world as Google — if not more; they vastly outnumber Amazon, for example — but they're insanely faster. That's because they barely have any real competition in what they do best: deliver content as close to the edge as possible, keeping latency at 10ms anywhere in the world, and do all of that seamlessly and transparent to the end-user (i.e., the developer). Their 'Workers' are just minimalistic JavaScript virtual machines that sit on their edge servers to do 'simple' tasks. Few things could be simpler than responding to a timestamp. Additionally, Cloudflare are the security experts of the Internet — their business model is designed around offering extra protection to all servers and services they protect, and they're really good at doing that. You can get equivalent service from all major cloud providers, of course, but none will be so easy to setup and have the same performance as Cloudflare — and they will charge a tiny fraction of what the Big Cloud providers charge for the same service (note: Cloudflare is not, strictly speaking, a 'cloud service provider'; instead, they do have their own cloud, on top of which they provide tons of services — even including Tor and IPFS gateways! — and 'Workers' is just one of the many things they do. I use them almost exclusively for registering and maintaining domain names — since they're not really in that business, they usually just charge the lowest possible annual fee, but you have to do all the setup on your own, and no, they don't provide 'web space' or similar products as the domain providers are so fond of doing).

Granted, again, if you get 'millions of calls' per day, even Cloudflare will charge you something — and a very substantial 'something' at that.

There is, of course, a completely free and forever unlimited source of reasonably good timestamp requests. It's simple: just take into account that every website in the world will provide a timestamp on the response headers. So, all you need is to retrieve a page from a website — I suggest retrieving the favicon.ico, which all popular servers will have, and it's guaranteed to exist with that name and a very small footprint (that's the whole point, after all). Also, even if you happen to use a website that does not have a favicon, that's okay, too, since even the error message will obviously carry a timestamp, too!

Thus, all you really need is a long list of popular websites (i.e., on the Top 100 list of most visited ones, which you can get from several sources, such as Netcraft or possibly Statista), and rotate the requests you make randomly across the list. The likelihood of getting blocked by them is comparatively low — they handle 'millions of requests' per second, and an extra million or so will hardly make a difference. It's also irrelevant what you call, favicon.ico or stemap.xml or robots.txt (all of which are 99% certain to exist on the 'top 100' list), but just be aware that calling something that gives a 404 error will show up on the logs, and might make a sysadmin suspicious (since all in-world LSL calls will come from the same block of Amazon IP addresses). Retrieving existing pages/files, however, is a much safer solution; unless you do billions of requests (and why should you do that?), it's highly likely that your activity will never be noticed, and, if you just make a call per day (at most!), it'll be far more difficult to raise internal alerts for 'abusing' the system.

That said, just remember — if you make those calls from within the Second Life Grid, and if your scripts go wild, not only will you be stopped for abuse by whichever service/solution you're using, but, additionally, you'll be very likely going to be banned as well, if LL gets a serious complaint.

— Gwyneth Llewelyn (talk) 04:24, 30 January 2025 (PST)