4 ms·
> I'd probably ask what the problem was that created this thought, maybe there's an answer to that instead. OP here. That article is old and I really wish it w
by Udo 13y ago
> I'd probably ask what the problem was that created this thought, maybe there's an answer to that instead.
OP here. That article is old and I really wish it wasn't on the front page. If I remember correctly, at the time this was written, there were some pretty big outages and failures that originated from apps assuming time was pretty much a linear monotonic value. So the motivation to write this was not only for myself, but to attempt and find a better solution for timestamps as needed by many apps.
There is no technical reason for the timestamp to jump around, and to convert to and from "human" time we already need libraries (especially if we're looking at points in the past or the future), so the argument that system timestamps MUST map to actual time of day is somewhat moot. As it is, the Unix timestamp attempts to be somewhat in the middle, in the end satisfying neither computer nor human requirements. So the idea was to separate those two timing formats completely.
- pdonis 13y agoa linear monotonous value I think you mean "monotonic". Though lots of non-geeks would probably say that "monotonous" applies too. :-)
- Udo 13y agoYou're right. Corrected.
- tel 13y agoThis exists, though it's rare to see any software that uses it. DJB's daemontools do, somewhat unsurprisingly. It's called TAI, International Atomic Time [0], and it's effectively just UTC minus the leap seconds. It's (close to) the actual time being measured by CPUs all about and it's a pain in the ass to convert to and from it due to leap seconds and such, but if you want to just make time somebody else's problem entirely then using TAI will keep you accurate at least. [0] http://en.wikipedia.org/wiki/International_Atomic_Time http://en.wikipedia.org/wiki/International_Atomic_Time