LiDARs and other sensors typically need to be time-synchronized with the rest of the robotic system. I wouldn't be surprised if the bug is related to that.
Shouldn't that just be a unix timestamp or something? You'd think resolving that to a date time could be done in the UI instead of in the business logic
Unix time has discrepancies whenever leap seconds occur (several times in my career aquiring geophysical data).
If you're measuring | controlling objects in the physical world (cars, rockets, etc) then you should not use unix time - those glitches will happen and instantaneous computations will go kooky.
But so does resolving to a date. I don't see how resolving to a date which cares about leap days fixes any of that.
You should use a monotonic clock with an arbitrary starting point anyway, unless you need some kind of synchronization between devices, but you probably wouldn't use unixtime there anyway.
> But so does resolving to a date. I don't see how resolving to a date which cares about leap days fixes any of that.
So why bring it up then?
> You should use a monotonic clock with an arbitrary starting point anyway
Sure. We started doing that more than 50 years ago now when broad area geophysical surveying started off.
> unless you need some kind of synchronization between devices,
Can't see the problem - there are ways of syncing base station records against aircraft | boat | vehicle records in post processing .. all the stations, fixed or mobile, use a monotonic epoch based record structure that hold channel data and any sync marks that are broadcast by whatever means - raw GPS time serves well enough for a grain of 1.5 seconds, other marks can be used as required.