[a_t48]

Clock sync is such a nightmare in robotics. Most OSes happily will skew/jump to get the time correct. Time jumps (especially backwards) will crash most robotics stacks. You might decide to ensure that you have synced time before starting the stack. Great, now your timestamps are mostly accurate, except what happens when you've used GPS as your time source, and you start indoors? Robot hangs forever.

Hot take: I've seen this and enough other badly configured time sync settings that I want to ban system time from robotics systems - time from startup only! If you want to know what the real world time was for a piece of data after, write what your epoch is once you have a time sync, and add epoch+start time.

[michaelt]

If your requirements are “must have accurate time, must start with an inaccurate time, must not step time during operation, no atomic clocks, must not require a network connection, or a WWVB signal, must work without a GPS signal” then yes, you need to relax your requirements.

But it doesn’t have to be the first requirement you relax.

[a_t48]

If it has a GPS already, it’s really easy to fall into the trap of just using it, but point taken. Then main requirement is accurate moment to moment time. Using GPS as the master clock mostly makes sense there.

[RossBencina]

C++11 distinguishes system_clock from steady_clock. As you say, using system_clock is a bug.

[awesome_dude]

THIS is what will save us from the robot uprising!