What a mess. (Plus, time is relative, i.e. it depends on the frame of reference.)
Time is an illusion, Unix time doubly so
11–20 of 104 posts
Re: Time is an illusion, Unix time doubly so
#12From the GNU coretutils doc [1]:
Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set of trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time.
… It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion. …
—Robert Grudin, Time and the Art of Living.
[1] https://www.gnu.org/software/coreutils/manual/html_node/Date...
Re: Time is an illusion, Unix time doubly so
#13Very interesting detail about linux and setting the time back to a value such that the boot time is before the epoch, with monotonic clocks.
Shamelessly I'll here remind people to never use gettimeofday() to measure time. E.g. setting the time backwards used to cause any currently running "ping" command to hang. (they fixed it about 10 years after I sent them a patch)
More fun examples of bugs like that at https://blog.habets.se/2010/09/gettimeofday-should-never-be-...
Re: Time is an illusion, Unix time doubly so
#14Excellent write up, with very nice humorous style and clearly explaining the situation with the year 2038 problem.
Re: Time is an illusion, Unix time doubly so
#15very interesting stuff. wondering is there any in-depth walkthrough of the time keeping mechanisms in Linux?
Re: Time is an illusion, Unix time doubly so
#16Maybe I am misunderstanding the post, but for me the beauty of Unix time is precisely that all the weirdness with dates is abstracted away to the "conversion code" so that you only deal with "seconds". Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.
Re: Time is an illusion, Unix time doubly so
#17Maybe I am misunderstanding the post, but for me the beauty of Unix time is precisely that all the weirdness with dates is abstracted away to the "conversion code" so that you only deal with "seconds". Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.
> leap seconds
Unix time is UTC based, so it ignores leap seconds and deviates from how many seconds actually passed since the start of the epoch.
The actual number of seconds passed corresponds to TAI, but you can't convert future timestamps from TAI to UTC since you can't predict leap seconds, so you can't display future TAI timestamps using typical date notation.
> For recording and calculations, it doesn't.
Depends on what you're recording and calculating. Storing a UTC timestamp generally works when recording an event that already happened.
But it doesn't work for scheduling events like meetings, since there the authoritative time is often local time. If you simply store such future events in UTC you'll run into problems when the definition of the relevant timezone changes.
Re: Time is an illusion, Unix time doubly so
#18Maybe I am misunderstanding the post, but for me the beauty of Unix time is precisely that all the weirdness with dates is abstracted away to the "conversion code" so that you only deal with "seconds". Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.
> Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely… the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems.
Excerpt From A Deepness in the Sky by Vernor Vinge
Re: Time is an illusion, Unix time doubly so
#19Maybe I am misunderstanding the post, but for me the beauty of Unix time is precisely that all the weirdness with dates is abstracted away to the "conversion code" so that you only deal with "seconds". Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.
> leap seconds Unix time is UTC based, so it ignores leap seconds and deviates from how many seconds actually passed since the start of the epoch. The actual number of seconds passed corresponds to TAI, but you can't convert future timestamps from TAI to UTC since you can't predict leap seconds, so you can't display future TAI timestamps using typical date notation. > For recording and calculations, it doesn't. Depen…
deleted
Re: Time is an illusion, Unix time doubly so
#20Earlier quoted context omitted.
> leap seconds Unix time is UTC based, so it ignores leap seconds and deviates from how many seconds actually passed since the start of the epoch. The actual number of seconds passed corresponds to TAI, but you can't convert future timestamps from TAI to UTC since you can't predict leap seconds, so you can't display future TAI timestamps using typical date notation. > For recording and calculations, it doesn't. Depen…
deleted
Fixed, thanks. I always confuse those.