4 ms·
His main beef seems to be that time isn't as simple as i++ and he really wish it were. But that's a lot to do with the fact that time is based on the spin and o
by buro9 13y ago
His main beef seems to be that time isn't as simple as i++ and he really wish it were. But that's a lot to do with the fact that time is based on the spin and orbit of Earth around the sun.
I think, that he's seriously suggesting that we find a unit of time that can be guaranteed to just increment and not be subject to leap stuff or calendar adjustments and can go forward and backwards in time as simple increments and decrements.
A de-coupling between the time counter and our perception of time as a human concept.
Maybe use the concept of a second, but not in relation to our calendar. So instead of being "seconds since 1970" it's just "seconds".
I guess the idea being that you'd have a guaranteed increment only counter for seconds that have passed, but without coupling that to an actual calendar.
I'd probably ask what the problem was that created this thought, maybe there's an answer to that instead.
- 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
- vacri 13y agoMaybe use the concept of a second, but not in relation to our calendar. So instead of being "seconds since 1970" it's just "seconds". Any counter you create will have a zero-point somewhere. 00:00 Jan 1 1970 isn't a point in time that moves around, same as any other zero point you elect to have.
- nl 13y agoI think, that he's seriously suggesting that we find a unit of time that can be guaranteed to just increment and not be subject to leap stuff or calendar adjustments and can go forward and backwards in time as simple increments and decrements. I have sympathy for this view. Back when I was doing time & date stuff I worked out a decimal calendar as a thought experiment. If you are happy to drop the idea that a "day" has to align with a period of daylight, and/or the "year" has anything to do with seasons then it's pretty easy...
- Leszek 13y agoOr just drop the idea of "day"/"year" being a fixed, constant integer number of seconds.