The clock on the router is wrong

The clock says 1 January 1970, or last week, or one hour away from everything else. Usually you notice it through something else: a browser complaining about a certificate, a backup that should have run at three and did not, or a log in which the events are not in the order they happened.

What it is not: a MikroTik sitting on a strange date after a power cut is not broken. Most RouterBOARDs have no battery behind the clock. They start on a fixed date and wait for NTP to correct them. The problem only starts when that correction does not happen, or happens after a few minutes in which the router has already done plenty.

Three things break immediately. Certificates have a validity window with a start and an end, and anything offered or created outside that window is invalid. Log lines get a timestamp, and a wrong timestamp makes a log worthless at the moment you need it. And the scheduler counts in days and hours: a job at 03:30 does not run when the router thinks it is 1970.

The quick checks, in order

1. What does the router think? /system clock print. A good answer: the right date, the right time, time-zone-name on your zone and time-zone-autodetect: no. A date from another decade means it has never synchronised.
2. Has NTP worked? /system ntp client print. A good answer: enabled: yes, status: synchronized and a last-update-from with an address in it. failed or stopped means it never got there.
3. Can it reach a time server? /ping nl.pool.ntp.org count=3. A good answer: replies. No reply, with an error about the name, means DNS is the problem and not NTP.
4. Does it resolve the name? :put [:resolve nl.pool.ntp.org]. A good answer: an IP address. An error here is the real cause, see DNS resolves nothing.
5. Which certificates exist, and from when? /certificate print detail. A good answer: invalid-before in the past and invalid-after far in the future. An invalid-before in 1970 or 2015 means that certificate was created while the clock was wrong.

The usual causes, most common first

DNS does not work, so NTP does not either

NTP servers are usually entered as names, not as addresses. If the router cannot look the name up, it finds no time server. This is the most common cause and a deceptive one, because everything points at the clock while the problem is DNS. There is a chicken and egg in it too: if you use DNS over HTTPS with certificate verification, that verification needs a correct clock, and the clock needs DNS. Put an IP address in as NTP server for the time being, for instance one of the addresses behind your pool.

The NTP client is off

A router set up by hand often does not have this on. Switch it on with /system ntp client set enabled=yes mode=unicast servers=....

The time zone is wrong, or autodetect guesses badly

One hour away from everything else is nearly always the zone or daylight saving. RouterOS can work the zone out from your public address, and it guesses wrong at a provider whose route comes out abroad. Set the zone by hand and switch autodetect off.

The certificate was created while the clock was still wrong

A self-signed certificate takes its start date from the moment it is signed. If that happens a second after the router booted and before NTP has landed, the start date is meaningless. Browsers respond to that in very different ways. The fix is not the clock but the certificate: remove it and create it again once the time is right. See Certificate warning.

What the configurator does about it

• The System section is always on, and it holds Time zone and NTP client. The NTP client is on by default, with nl.pool.ntp.org,time.cloudflare.com as servers. You can put your own addresses or names there.
• The script writes /system clock set time-zone-name=... time-zone-autodetect=no. That no is a choice: the zone you picked stays put, even when the public address moves or the provider comes out somewhere else.
• The clock lines sit in the script before the lines that create certificates. That helps, but it is no guarantee: NTP is not finished by the time the next line runs. If you paste a script onto a device that has just been powered on, check afterwards with /system clock print whether the time is right, and recreate the certificate if it is not.
• Management access has Update time via IP Cloud under IP Cloud. That is a second route to a correct clock, independent of your own NTP servers. Useful on a device whose time you do not trust, and it is off by default.
• What the tool does not do: it does not check whether the clock on the device is right at the moment you paste. It cannot know that, because the browser never talks to your router.

Everything that leans on time afterwards comes from the same place. The weekly backup from Services & tools runs at 03:30, the automatic update from System on Sunday at 04:00, and your own scripts at the start time you filled in. A router that thinks it is 1970 either does not run them or runs them all at once at the first synchronisation.

Where the cause lies outside your router

• The provider. Some networks steer NTP to their own server and that one can be off. Enter a public pool explicitly in that case.
• Your own time server. If you run NTP on a server in the LAN, check first that it is synchronised itself; a server that is not distributes its own error.
• The device that complains. A correct clock on the router and a day-old clock on the laptop produces the same certificate story. Check both ends.

Read on: System and time, Certificates and Logging.