time.enhost.uk
time.enhost.uk is a public Stratum 2 NTP server available for anyone to use. It provides accurate time synchronization for computers and devices.
Under the clock is the Unix timestamp: the number of seconds elapsed since 1 January 1970 00:00:00 UTC, known as the epoch. It has no timezone and no formatting to parse, which is why almost everything in computing stores time this way and converts to a local clock only for display. It also ignores leap seconds, so it counts every day as exactly 86,400 seconds. A signed 32-bit timestamp runs out on 19 January 2038, which is why modern systems use 64 bits.
Beside it is Swatch Internet Time, the .beat clock Swatch
introduced in 1998 to do away with timezones. The day is split into 1000 beats of 86.4 seconds, counted
from midnight Biel Mean Time (UTC+1, no daylight saving): @000 is midnight
in Biel, @500 is midday, and the beat is the same everywhere on earth. It is also in the
JSON response as swatch_internet_time and in the X-Swatch-Beat header.
The same instant, counted the other ways people and machines count it. These run live, from the same NTP-corrected clock as the display above. The date and day-based values follow the timezone selected at the top of the page; Julian, sidereal and Martian time have no timezone at all.
2026-W41-7. Standard in manufacturing and
payroll, where "week 41" is more useful than a date.0:00:00 and midday exactly 5:00:00. A decimal hour is 2.4 ordinary
hours and a decimal minute is 86.4 seconds — the same length as a Swatch beat, arrived at
independently two centuries apart. Made optional after seventeen months and abandoned, which is
why nobody owns a decimal watch. Follows local time, as the original followed local solar
time.week:seconds. The week number is the value
that wraps every 1024 weeks — see Epochs and Rollovers below..0000 to .FFFF. A hobbyist
scheme rather than a standard; the last digit ticks about every 1.3 seconds.UTC is kept within 0.9 seconds of the earth's rotation by inserting leap seconds, while the atomic scales run without interruption. That is why they disagree by a whole number of seconds: TAI = UTC + 37s and GPS = UTC + 18s. Unix time has no way to represent a leap second at all, which is why it treats every day as exactly 86,400 seconds.
27 leap seconds have been inserted since 1972, the last on 2017-01-01. None has been added since, and in 2022 the CGPM resolved to discontinue them by 2035, so the offset is expected to stay at 37s.
GPS numbers its weeks from 6 January 1980 and is currently in week 2444. The legacy navigation message carries only 10 bits for that number, so it wraps every 1024 weeks — about every 19.6 years. It has done so 2 times, most recently on 2019-04-07, and will again on 2038-11-21. Receivers that assumed otherwise failed on both previous occasions; modern signals use a 13-bit field worth about 157 years.
Not everyone inserts them. Google, Amazon and others apply a leap smear, stretching the surrounding day so clocks never read 23:59:60 — which keeps software happy but means their time can sit up to half a second away from UTC either side of the event.
| Effective (UTC) | Inserted at | TAI−UTC |
|---|---|---|
| 1972-01-01 | — start of whole-second UTC | 10s |
| 1972-07-01 | 1972-06-30 23:59:60 | 11s |
| 1973-01-01 | 1972-12-31 23:59:60 | 12s |
| 1974-01-01 | 1973-12-31 23:59:60 | 13s |
| 1975-01-01 | 1974-12-31 23:59:60 | 14s |
| 1976-01-01 | 1975-12-31 23:59:60 | 15s |
| 1977-01-01 | 1976-12-31 23:59:60 | 16s |
| 1978-01-01 | 1977-12-31 23:59:60 | 17s |
| 1979-01-01 | 1978-12-31 23:59:60 | 18s |
| 1980-01-01 | 1979-12-31 23:59:60 | 19s |
| 1981-07-01 | 1981-06-30 23:59:60 | 20s |
| 1982-07-01 | 1982-06-30 23:59:60 | 21s |
| 1983-07-01 | 1983-06-30 23:59:60 | 22s |
| 1985-07-01 | 1985-06-30 23:59:60 | 23s |
| 1988-01-01 | 1987-12-31 23:59:60 | 24s |
| 1990-01-01 | 1989-12-31 23:59:60 | 25s |
| 1991-01-01 | 1990-12-31 23:59:60 | 26s |
| 1992-07-01 | 1992-06-30 23:59:60 | 27s |
| 1993-07-01 | 1993-06-30 23:59:60 | 28s |
| 1994-07-01 | 1994-06-30 23:59:60 | 29s |
| 1996-01-01 | 1995-12-31 23:59:60 | 30s |
| 1997-07-01 | 1997-06-30 23:59:60 | 31s |
| 1999-01-01 | 1998-12-31 23:59:60 | 32s |
| 2006-01-01 | 2005-12-31 23:59:60 | 33s |
| 2009-01-01 | 2008-12-31 23:59:60 | 34s |
| 2012-07-01 | 2012-06-30 23:59:60 | 35s |
| 2015-07-01 | 2015-06-30 23:59:60 | 36s |
| 2017-01-01 | 2016-12-31 23:59:60 | 37s |
1972-01-01 is not itself a leap second: it is when UTC adopted whole seconds, starting the offset at 10. The 27 rows after it are the insertions, giving 37s today.
Every one of these counters is a fixed number of bits, so every one of them runs out. These are the ones still ahead of us, and they arrive within three years of each other:
NTP counts 32 unsigned bits of seconds from 1900, which fills on
7 February 2036. The protocol defines era numbering to carry on past it, so this is a
problem for implementations that ignored eras rather than for NTP itself.
Unix time in a signed 32-bit time_t overflows on
19 January 2038; 64-bit systems are unaffected, which is most but not all of them.
GPS wraps its legacy 10-bit week number again on 21 November 2038.
| System | Epoch | Notes |
|---|---|---|
| Julian Date | 4713 BC-01-01 | Noon, proleptic Julian calendar; used in astronomy |
| Windows FILETIME | 1601-01-01 | Counts 100-nanosecond intervals |
| NTP | 1900-01-01 | The protocol this server speaks |
| Classic Mac OS | 1904-01-01 | Chosen so no leap-year special case was needed |
| Unix | 1970-01-01 | Seconds, ignoring leap seconds |
| GPS | 1980-01-06 | Weeks and seconds-of-week, no leap seconds |
| J2000.0 | 2000-01-01 | Noon TT; reference for modern astronomical formulae |
| Date (UTC) | Full week | 10-bit week | |
|---|---|---|---|
| 1980-01-06 | 0 | 0 | — GPS epoch, start of the count |
| 1999-08-22 | 1024 | 0 | wrapped |
| 2019-04-07 | 2048 | 0 | wrapped |
| 2038-11-21 | 3072 | 0 | due |
| 2058-07-07 | 4096 | 0 | due |
| 2078-02-20 | 5120 | 0 | due |
Each row is 1024 weeks after the one above it, the point at which the legacy 10-bit week number returns to zero. A receiver that does not account for it reports a date 19.6 years in the past.
Stratum: 2
NTP Pool: View server statistics
Pool Zones: Global, Europe, UK
Upstream servers:
Note: For the best reliability, we recommend using pool.ntp.org which automatically load-balances across multiple servers worldwide. However, you're welcome to use our server time.enhost.uk directly.
Add the following to your NTP configuration:
server time.enhost.uk iburst
Windows 11/10:
1. Open Settings → Time & Language → Date & Time
2. Scroll down and click "Additional clocks"
3. Click "Internet Time" tab → "Change settings"
4. Enter time.enhost.uk (or pool.ntp.org) as the server
5. Click "Update now" then "OK"
macOS Ventura or later:
1. Open System Settings → General → Date & Time
2. Click the info (ⓘ) button next to "Set time and date automatically"
3. Enter time.enhost.uk (or pool.ntp.org) as the time server
4. Click "OK"
macOS Monterey or earlier:
1. Open System Preferences → Date & Time
2. Click the lock to make changes
3. Click "Set time and date automatically" and enter time.enhost.uk (or pool.ntp.org)
Using AtomicClock App (macOS/iOS):
1. Install AtomicClock - NTP Time from the App Store
2. Open the app and go to Settings
3. Enter time.enhost.uk (or pool.ntp.org) as the NTP server
4. Use the app to view accurate time from our server
Using AtomicClock App:
iOS doesn't allow changing the system NTP server, but you can use an app to view accurate time from our server.
1. Install AtomicClock - NTP Time from the App Store
2. Open the app and go to Settings
3. Enter time.enhost.uk (or pool.ntp.org) as the NTP server
4. Use the app to view accurate time from our server
Note: This app displays the accurate time but cannot synchronize your iOS device's system clock. iOS automatically syncs with Apple's time servers.
systemd-timesyncd (Ubuntu/Debian):
sudo nano /etc/systemd/timesyncd.conf
Add under [Time]:
NTP=time.enhost.uk
(or use pool.ntp.org)
Then restart:
sudo systemctl restart systemd-timesyncd
chrony (RHEL/CentOS/Fedora):
echo "server time.enhost.uk iburst" | sudo tee -a /etc/chrony.conf
(or use pool.ntp.org)
sudo systemctl restart chronyd
NixOS:
Add to your configuration.nix:
networking.timeServers = [ "time.enhost.uk" ];
(or use [ "pool.ntp.org" ])
Then rebuild:
sudo nixos-rebuild switch
Standard Android:
Android uses automatic time from cellular networks by default and doesn't allow custom NTP servers through settings.
Using AtomicClock App (No Root):
1. Install AtomicClock - NTP Time from Google Play
2. Open the app and go to Settings
3. Enter time.enhost.uk (or pool.ntp.org) as the NTP server
4. Use the app to view accurate time from our server
With Root Access:
1. Install ClockSync from F-Droid
2. Open the app and grant root permissions
3. Enter time.enhost.uk (or pool.ntp.org) as the NTP server
4. Enable automatic sync
Query the NTP server directly from the command line:
Using ntpdate (query only):
ntpdate -q time.enhost.uk
Using ntpdate (sync immediately, requires root):
sudo ntpdate time.enhost.uk
Using sntp:
sntp time.enhost.uk
Using ntpq (query NTP daemon):
ntpq -p time.enhost.uk
Using chronyc (if using chrony):
chronyc tracking
Raw UDP query with netcat:
printf '\x1b' | nc -u -w1 time.enhost.uk 123 | od -A x -t x1z -v
Note: NTP uses UDP on port 123, so standard tools like cURL and telnet won't work.
Get NTP time via HTTP API:
https://time.enhost.uk/
Note: This API includes processing delay from querying the NTP server and PHP execution time.
The processing_time_ms field shows how long the server took to process the request.
For time-critical applications, use the NTP protocol directly (port 123).
JSON response (with Accept: application/json header):
{
"success": true,
"enhost_ntp": {
"server": "time.enhost.uk",
"timestamp": 1707494400,
"timestamp_ms": 1707494400000,
"unix_timestamp": 1707494400.123,
"iso8601": "2024-02-09T16:00:00.000Z",
"rfc2822": "Fri, 09 Feb 2024 16:00:00 GMT",
"ntp_request_time_ms": 8.3,
"processing_time_ms": 8.3
},
"uk_pool_ntp": { "...": "same shape, from uk.pool.ntp.org" },
"swatch_internet_time": {
"beats": 750.0,
"beat": 750,
"display": "@750.00",
"reference": "Biel Mean Time (UTC+1), 1000 beats per day"
},
"timezone": {
"name": "Europe/London",
"abbreviation": "GMT",
"utc_offset": "+00:00",
"offset_seconds": 0,
"local_time": "2024-02-09 16:00:00",
"iso8601": "2024-02-09T16:00:00.000+00:00",
"dst": false,
"next_transition": {
"at": "2024-03-31T01:00:00Z",
"at_local": "2024-03-31 02:00:00",
"abbreviation": "BST",
"utc_offset": "+01:00",
"offset_seconds": 3600,
"dst": true,
"shift_seconds": 3600,
"direction": "forward"
}
},
"decimal_time": {
"hours": 5, "minutes": 0, "seconds": 0,
"display": "5:00:00",
"decimal_seconds": 50000.0,
"timezone": "Europe/London",
"reference": "10 hours of 100 minutes of 100 seconds, from local midnight"
},
"leap_seconds": {
"tai_utc_offset": 37,
"gps_utc_offset": 18,
"inserted": 27,
"last_inserted": "2017-01-01",
"note": "TAI = UTC + 37s. ..."
},
"gps_time": {
"gps_seconds": 1475785836,
"week": 2440,
"week_legacy": 392,
"seconds_of_week": 73836,
"day_of_week": 0,
"gps_utc_offset": 18,
"rollovers_so_far": 2,
"last_rollover": "2019-04-07",
"next_rollover": "2038-11-21",
"note": "..."
},
"upcoming_rollovers": [
{ "name": "NTP era 0", "at": "2036-02-07 06:28:16", "years_away": 9, "note": "..." },
{ "name": "Unix 32-bit time_t", "at": "2038-01-19 03:14:07", "years_away": 11, "note": "..." },
{ "name": "GPS week number", "at": "2038-11-21 00:00:00", "years_away": 12, "note": "..." }
],
"other_scales": {
"iso_week_date": "2026-W41-7", "ordinal_date": "2026-284",
"julian_date": 2461325.37766, "modified_julian_date": 61324.87766,
"sidereal_time": "22:25:41",
"mars_sol_date": 54310.31699, "mars_coordinated_time": "07:36:27",
"kiloseconds": 79.43, "hexadecimal": ".EB59",
"timezone": "Europe/London",
"tick": { "...": "value plus rate, so a client can tick these without the formulae" }
},
"offset_ms": -1.2,
"processing_time_ms": 12.5
}
Headers-only response (HEAD request):
For minimal overhead, use a HEAD request to get time data in response headers only:
X-NTP-Timestamp: 1707494400
X-NTP-Timestamp-Ms: 1707494400000
X-NTP-ISO8601: 2024-02-09T16:00:00.000Z
X-NTP-RFC2822: Fri, 09 Feb 2024 16:00:00 GMT
X-NTP-Request-Time-Ms: 8.3
X-NTP-Processing-Time-Ms: 12.5
X-NTP-Offset-Ms: -1.2
HEAD carries the time and this request's own timings only. Every other scale on this page
— .beat, decimal, Julian, sidereal, Martian, GPS, the timezone block and the
upcoming rollovers — is in the JSON response instead, so a HEAD stays cheap.
Timezone:
Add tz= with an IANA name to get the same instant as a local wall clock in the
timezone block, along with the zone's next daylight-saving change in
next_transition (null for zones that have none). Timestamps and
iso8601 stay UTC regardless. Defaults to UTC; an unknown name returns HTTP 400.
curl 'https://time.enhost.uk/?json=1&tz=Asia/Tokyo'
Using cURL (JSON):
curl -H "Accept: application/json" https://time.enhost.uk/
Using cURL (HEAD request):
curl -I https://time.enhost.uk/?json
Using JavaScript/Fetch:
fetch('https://time.enhost.uk/', {
headers: { 'Accept': 'application/json' }
})
.then(res => res.json())
.then(data => console.log(data.iso8601));
Using the ntp-client package:
const ntpClient = require('ntp-client');
ntpClient.getNetworkTime('time.enhost.uk', 123, (err, date) => {
if (err) {
console.error(err);
return;
}
console.log('Current time:', date);
});
Install with: npm install ntp-client
Or using the HTTP API with axios:
const axios = require('axios');
axios.get('https://time.enhost.uk/', {
headers: { 'Accept': 'application/json' }
})
.then(response => {
console.log('Time:', response.data.iso8601);
});
Using the ntplib library:
import ntplib
from time import ctime
client = ntplib.NTPClient()
response = client.request('time.enhost.uk')
print(ctime(response.tx_time))
Install with: pip install ntplib
Using sockets to query NTP server:
$server = 'time.enhost.uk';
$port = 123;
$socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_set_option($socket, SOL_SOCKET, SO_RCVTIMEO,
array('sec' => 5, 'usec' => 0));
$msg = chr(0x1b) . str_repeat(chr(0), 47);
socket_sendto($socket, $msg, strlen($msg), 0, $server, $port);
socket_recvfrom($socket, $response, 48, 0, $server, $port);
$data = unpack('N12', $response);
$timestamp = $data[11] - 2208988800;
echo date('Y-m-d H:i:s', $timestamp);
Using the rsntp crate:
use rsntp::SntpClient;
fn main() {
let client = SntpClient::new();
let result = client.synchronize("time.enhost.uk")
.unwrap();
println!("Time: {:?}", result.datetime());
}
Add to Cargo.toml: rsntp = "3.0"
Using UDP sockets to query NTP server:
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <time.h>
#define NTP_TIMESTAMP_DELTA 2208988800ull
int main() {
int sockfd;
char packet[48] = {0x1b, 0};
struct sockaddr_in serv_addr;
struct hostent *server;
server = gethostbyname("time.enhost.uk");
sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
memset(&serv_addr, 0, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
memcpy(&serv_addr.sin_addr.s_addr, server->h_addr, server->h_length);
serv_addr.sin_port = htons(123);
sendto(sockfd, packet, sizeof(packet), 0,
(struct sockaddr *)&serv_addr, sizeof(serv_addr));
recvfrom(sockfd, packet, sizeof(packet), 0, NULL, NULL);
unsigned long secsSince1900 = (packet[40] << 24) | (packet[41] << 16) |
(packet[42] << 8) | packet[43];
time_t epoch = secsSince1900 - NTP_TIMESTAMP_DELTA;
printf("Time: %s", ctime(&epoch));
return 0;
}
Compile with: gcc -o ntp_client ntp_client.c
A note on accuracy: the NTP server itself is highly accurate and can be relied on by operating systems, as in the configuration examples above. The clock on this page, though, is fetched over HTTP and carries network latency and processing delay, so the offsets shown here are approximate. For real synchronisation, point your system at the NTP server directly.