This is a harder problem than it seems. I've been thinking and reading about it for a side project, but haven't done much testing yet.

There are a few places to get the current time:

- on-board real-time clock (RTC) connected to a continuous power source (e.g. button battery)

- GPS

- Colorado WWVB signal (60 KHz), Frankfurt DCF-77 (77.5 KHz), Cumbria NPL (60 KHz)

- the internet (NTP, HTTPS servers, etc.)

- mobile internet (e.g. LTE)

- estimate time elapsed between power cycles by tracking and storing IEEE 802.11 timing synchronization function (TSF) timestamps from nearby wifi routers.

All of these are potentially problematic.

The best option is the RTC. Buy a DS3231, hook it up to your microcontroller and a button battery, and forget about it for a few years. The only problem with these (besides the battery) is that they can drift pretty badly. The fancy ones account for temperature fluctuations and are accurate to ~2 ppm, which is one minute per year. Aside from the drift, it sucks to need an always-on dedicated IC just to know the time, especially if you don't always need to know the time.

GPS is nice but it's hard to get a signal indoors, especially in a skyscraper far away from a window, as can happen here in New York. You also need a relatively bulky component and an antenna.

The longwave radio signals (WWVB, DCF-77, and NPL) are neat and old and what "atomic clocks" use, but the signal is tiny and you need a sensitive long-running receiver, either with a gigantic antenna or a slightly less gigantic ferrite rod. Even then, one of those cheap atomic clocks might not sync at all unless it's placed near a window. The WWVB signal is also very weak in certain parts of America and at certain times of day, so your circuit might only get a bit of signal over the noise once or twice a day, which might or might not be enough to deduce the time.

The plain old internet works fine, but then your power budget involves a wifi radio, though you only need to run it for a few hundred milliseconds per hour. You also need a wifi password, which is a pain to configure in an IoT device. Also, you wanted a clock, why does it need the internet? GTFOOH.

Mobile internet is way overkill.

The last idea is something I haven't tested fully, since my microcontroller (raspberry pi pico w) can't keep up with the "promiscuous mode" unofficially offered by its wifi chip. It's a neat idea, though: you're in an environment with wifi routers all around, and you want to guess the time elapsed since you last checked by listening, without credentials, to the chatter. With enough routers and some flash storage you can probably keep track of time, assuming the whole area doesn't get a power outage.

That's my very long way of saying that keeping time is a solved problem but all of the solutions have drawbacks and none works perfectly.