Clocks, and why they matter more than you think

A game server's clock is the one piece of infrastructure nobody checks, and it is behind a small set of bugs that are almost impossible to diagnose from their symptoms, because the symptom is never "the clock is wrong".

What breaks when the clock drifts

Scheduled restarts fire at the wrong time. A restart set for 06:00 that happens at 06:40 is a restart during somebody's morning session, and the owner sees a restart that ran and concludes the schedule is fine.

Certificates fail. TLS validity is checked against the local clock. A server whose clock is days out rejects valid certificates, or accepts expired ones, and the error message is about the certificate rather than the time.

Log correlation becomes impossible. Two machines with clocks a minute apart produce logs that cannot be lined up. When you are trying to establish whether the database stall caused the tick spike or followed it, a minute of skew makes the question unanswerable.

Timed game mechanics misbehave. Anything with a real-world schedule (wipes, events, decay, daily rewards) computes against the system clock. A drifted clock produces a wipe an hour early, and players do not experience that as a clock problem. On a game where the wipe calendar is the community calendar, that hour is not a technical detail.

It is one line

Modern Linux ships a time synchronisation service and it is usually already running. The check is quick:

timedatectl

The two lines to look at are whether the NTP service is active and whether the clock is synchronised. If both say yes, this is a solved problem on your machine and you can stop reading.

If either says no, turning it on is a single command and no restart of anything else.

Run the server in UTC

Not because UTC is better in the abstract, because it has no daylight saving.

A server on a local timezone that observes DST shifts by an hour twice a year. Everything scheduled against local time moves with it: restarts, backups, wipes, events. Once a year that means an hour earlier than intended, once a year an hour later, and both arrive without anybody changing anything.

The failure is worse than it sounds because it is annual. Nobody remembers what happened last October, so it is diagnosed fresh both times.

Set the machine to UTC, schedule everything in UTC, and translate to local time only when communicating with players. That is the arrangement that is correct permanently rather than for half the year.

The consequence for announcements

If your server runs on UTC and your players do not, every announced time needs translating, and getting that wrong produces a community that turns up an hour out for a scheduled event.

State times in UTC and give a local equivalent for your largest population. Most communities coordinate through Discord anyway, which renders timestamps in each reader's own timezone if you use the right format — a small thing that removes a whole category of confusion, and worth setting up properly once.

Where it actually bites

Containers inherit the host's clock but not necessarily its timezone, so a container can be correct and report times you do not expect. On a panel-hosted server the timezone may be the host's rather than yours, and neither is wrong — they are simply different, and the scheduled restart you configured is in whichever one the panel used.

Check what the server thinks the time is, from inside, before trusting anything scheduled.

Leap seconds and the thing that is no longer a problem

For years the standard advice included worrying about leap seconds, which could make a clock repeat or skip a second and produce genuinely strange behaviour in software that assumed time only moves forward.

Modern time services smear the adjustment across hours rather than applying it instantly, which removes the failure for anything that is not doing high-frequency trading. It is worth knowing mainly so you can ignore guides that still treat it as a live concern: the same reason most tuning advice found in forum posts is describing a problem that was fixed several years before you read it.

Two minutes, once

Confirm time sync is running. Set the machine to UTC. Schedule everything in UTC. Note somewhere what timezone your announcements use.

It is the least interesting maintenance on the list and it removes a class of bug that is genuinely hard to find afterwards: the kind where every individual symptom leads somewhere else, and reading the logs is actively misleading because the timestamps are lying.