Converting a $3.88 analog clock from Walmart into a ESP8266-based Wi-Fi clock

GPS isn't too hard, either.

The receivers are inexpensive ($5-$10 for the kind of accuracy that's useful here) and it's not hard to parse the NMEA strings and PPS they output into a spooky-accurate internal clock. It only takes a few connections and an antenna to integrate GPS into an MCU like an ESP (or an SBC like a Raspberry Pi or a whatever).

Like, really: The hardware is ridiculously easy.

The only difficult part is the code. But as we can see from this posting, the clock-driving bits are already written and are available for use.

Just graft in the GPS parts instead of the NTP parts, add your DST/location rules if you really must (hint: that part is harder than it sounds), and send it.

(And if the code still seems arduous, then remember: This is the kind of work that a reasonably-focused person who is armed with a decent bot can put together over a cup of coffee or two, even if they don't speak C. It may be popular here to poo-poo the bot here, but it's completely OK to get some help. Don't let pride get in the way of having fun, learning things, and building neat stuff.

The tailor doesn't lament the invention of the cotton gin.)

What a great idea. Legacy VCR controls upcycled for digital control! There's a lot of those old decks and LANC deck controllers lying around...

This is a hard problem. Solvable only with try and error.

Those signals are just weird mess of coils, switches and resistors.

ESP32 clock speed may also be a contributing factor.

This is cool but it seems like it would be liable to drift. I.e. it "knows" the correct time but doesn't have any way to figure out that it's been driving the movement fast or slow by some number of milliseconds. Eventually, that will pile up to the point that it's not any better than running the thing off of batteries.

As the author points out, the cheap quartz mechanism has no way of reporting the position of the hands (other than the hands themselves) and that you have to set the PULSETIME constant by the right number of milliseconds. If you're off by even a millisecond, that's going to accumulate quick enough that it would make a difference over even a single day, wouldn't it?

EDIT: as some have pointed out, the Lavet stepper theoretically accounts for this in that it steps exactly one tick after so many oscillations. That number of oscillations does not change so that's all you need to get right.

However, that basically just kicks the can down the road a bit in that if each step is not exactly 1/60th of a circle or bits wear down or get sticky or you have analog noise in there you will presumably still have a source of biased drift that you won't be able to detect. But maybe those affects are small enough that they don't matter for a wall clock.

What's the best way to periodically get time and date if your customers are big businesses with hostile IT departments?