Is there an alternative to NTP for getting the time?

For keeping an operating system's clock in sync, NTP (or a variant such as Chrony or Windows Time) is the standard. When NTP is not an option, for example in a browser, behind a firewall that blocks UDP port 123, or when you need the local time in a zone, an HTTPS time API returns the current time in one request.

Can I use NTP from JavaScript in a browser?

No. Browsers cannot send UDP packets, and NTP uses UDP port 123. Web pages get trusted time from an HTTP(S) endpoint instead.

Is an HTTP time API as precise as NTP?

No, and it does not need to be for most apps. NTP measures and compensates network delay continuously to keep clocks within milliseconds. An HTTP API answers within one round trip; correcting by half the round trip is usually well inside what countdowns, logs, licences and dashboards need.

What is a reliable time source for an application?

For the server clock: the operating system's NTP service pointed at a reputable pool. For application logic that must not trust the device clock (client apps, kiosks, IoT boards, license checks): a time API over HTTPS, optionally with signed responses so the timestamp can be verified later.

Can I prove which time a server returned?

With TimeLogic, add sign=true and the response carries an Ed25519 signature over the status, method, path and query, a signing timestamp and the body's SHA-256, which anyone can verify with the public key. It is not an RFC 3161 time-stamp token.

NTP vs Time API: Get Reliable Time from the Internet

NTP or an HTTPS time API? When each is the better time source: browsers, blocked UDP, time zones and DST, signed timestamps and devices with wrong clocks.

Short answer: use NTP to keep a computer's clock correct; use an HTTPS time API when your code needs the time and cannot rely on the local clock, for example in a browser, on a network that blocks NTP, on a device that has just booted, or when you need the local time in a specific zone with DST applied.

NTP and a time API compared

Feature	NTP	HTTPS time API (TimeLogic)
Job	Keep the system clock in sync	Give your code the current time on request
Transport	UDP port 123	HTTPS port 443
Works in a browser	No	Yes (CORS enabled)
Precision	Milliseconds or better, continuously corrected	One round trip; correct by half of it
Output	UTC	UTC, Unix seconds and ms, local ISO 8601 with offset, RFC 2822, weekday
Time zones and DST	Not part of NTP	Applied from the IANA tz database; zone from name, IP or coordinates
Proof of the time	Not built in (NTS secures the channel)	Optional Ed25519 signed responses
Needs a key	No	Yes (Free plan: 10,000 requests per month)

When is an HTTP time API the better choice?

Web pages and single-page apps. Browsers cannot speak NTP. Fetch the time once from a current time API and keep an offset in JavaScript.
Networks that block UDP 123. Corporate, school and hotel networks often allow only HTTPS. One request still gets the time.
Devices without a battery-backed clock. A Raspberry Pi or ESP32 can learn the time and its local zone at boot.
You need local time, not just UTC. GET /v1/time/current?tz=Europe/Paris already has the offset and DST applied; NTP leaves that to you.
You must not trust the user's clock. Trial periods, exams, auctions and licence checks break when users change their clock. Ask the server.
You need evidence. Signed responses let you store a timestamp together with a signature anyone can check.

When should I stay with NTP?

Keep NTP (or systemd-timesyncd, chrony, Windows Time) for the operating system clock of every server and computer. Logs, TLS certificates and schedulers rely on it, and an HTTP API is not a replacement for clock discipline. Most production systems use both: NTP for the machine, the API for application logic that needs a trusted or zone-aware time.

Get the time from the internet in one request

curl "https://api.timelogicapi.com/v1/time/current?tz=UTC&api_key=$TIMELOGIC_API_KEY"

{
  "unix": 1793377374,
  "unix_ms": 1793377374673,
  "utc": "2026-10-30T16:22:54Z",
  "iso_local": "2026-10-30T16:22:54+00:00",
  "rfc2822": "Fri, 30 Oct 2026 16:22:54 +0000",
  "human": "October 30, 2026, 4:22 PM Etc/UTC",
  "day_number": 6,
  "day_short": "Fri",
  "day_full": "Friday",
  "timezone": "Etc/UTC"
}

How long does one request take?

Server-side, excluding network, the API answered in a median of 18.1 ms with a p95 of 27.9 ms (1,000 paired warm requests at Cloudflare's Austin edge, October 30, 2026). It runs at the edge on Cloudflare's network, so one request costs your round trip to the nearest edge plus that server time. The best end-to-end run on record: on October 25, 2026, warm requests answered by Cloudflare's Seattle edge took a median of 35 ms and a p95 of 39.4 ms, network included (20 sequential requests to /v1/timezone). Real-world latency also depends on your connection and distance to the nearest edge. Every measurement, with its date and route, is listed in llms-full.txt.

NTP vs a time API: how to get reliable time from the internet