Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time is an illusion, Unix time doubly so

netmeister.org

Post reply on HN
Print view View original

21–30 of 104 posts

Re: Time is an illusion, Unix time doubly so

#21

Post by mannykannot »

"On Unix systems we measure time as the number of seconds since "the epoch": 00:00:00 UTC on January 1st, 1970.... this definition is not based on something sensical such as, say, the objective frequency of vibration of a Cesium-133 atom, but on a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis."

Well, seconds have not been defined as "a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis" for quite some time, and the origin is set to an abstract event in the past, which is not (as far as I know) subject to retroactive revision as a consequence of the vagarities of planetary or celestial motion (if it is, I would be fascinated to know more.)

Re: Time is an illusion, Unix time doubly so

#22

Post by _jal »

samatman wrote: post #10
pfarrell wrote: post #6

Earlier quoted context omitted.

Mongodb, for one, will freak out if you set the system date into the future, interact with it, then set time back. It will think the indices are corrupt and refuse to start. At least that happened to me last year. IIRC, the time stamp is part of generated object ids, so it’s sort of understandable. In the end I returned by computer to the future date, exported data, and rebuilt my collections.

So anyone can bring down Mongo with a compromised ntp server? That's an inconvenient property to have.

Oh, if you own someone's clock, you can do all sorts of damage.

Want to expire everyone's passwords? Blow up their credit card processing? Those are just the obvious attacks.

Re: Time is an illusion, Unix time doubly so

#23

Post by friendzis »

gjulianm wrote: post #16

Maybe 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.

> Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.

You cannot, by definition, tell how many Unix seconds later "third of may, 2025, at noon, local time" is - there is no way to convert future, local times to Unix times, because that "conversion code" is not fixed. Sure, we can reasonably expect that definition of time flow relationship to local time will not change for past dates, but one must expect these changes for times in the future.

Re: Time is an illusion, Unix time doubly so

#24

Post by yakubin »

CodesInChaos wrote: post #17
gjulianm wrote: post #16

Maybe 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…

Unix time is not UTC-based. It counts the number of seconds passed since a certain point in time, which may be described as date and time expressed in any time zone you like. It just so happens that in UTC it is easiest to remember for a human what this point was, since you get a lot of zeroes at the end.

Edit: I’m not entirely correct here, as aside from UTC the time zone, there is also UTC the time standard. See below.

Re: Time is an illusion, Unix time doubly so

#26

Post by lazide »

mannykannot wrote: post #21

"On Unix systems we measure time as the number of seconds since "the epoch": 00:00:00 UTC on January 1st, 1970.... this definition is not based on something sensical such as, say, the objective frequency of vibration of a Cesium-133 atom, but on a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis." Well, seconds have not been defined as "a convenient frac…

That’s a very recent change - and it’s not like 9192631770 transitions/hz (which is hilariously self referential!) is some obvious, natural value that ISN’T based on the historic ‘typical’ length of the day based on our rotation around the sun.

A second being 1/86400th of a day (24 hrs * 60 minutes * 60 seconds per minute) is still essentially true, and based, essentially still on the seasons and our movement around the sun (or relative movements between the various bodies in the solar system, depending).

Being a chaotic natural system, we of course need to add fudge factors here and there to simplify the math day to day while keeping it aligned with observed reality, like leap seconds and all), at least where it intersects with reality in a material way.

Re: Time is an illusion, Unix time doubly so

#27

Post by ericpauley »

yakubin wrote: post #24
CodesInChaos wrote: post #17

Earlier 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…

Unix time is not UTC-based. It counts the number of seconds passed since a certain point in time, which may be described as date and time expressed in any time zone you like. It just so happens that in UTC it is easiest to remember for a human what this point was, since you get a lot of zeroes at the end. Edit: I’m not entirely correct here, as aside from UTC the time zone, there is also UTC the time standard. See be…

Unix time is UTC-based, in that the leap second corrections applied to UTC are also simultaneously applied to Unix time (as people tend to use it).

Re: Time is an illusion, Unix time doubly so

#28

Post by krisoft »

mannykannot wrote: post #21

"On Unix systems we measure time as the number of seconds since "the epoch": 00:00:00 UTC on January 1st, 1970.... this definition is not based on something sensical such as, say, the objective frequency of vibration of a Cesium-133 atom, but on a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis." Well, seconds have not been defined as "a convenient frac…

> seconds have not been defined as "a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis" for quite some time

That is true.

> origin is set to an abstract event in the past

That is also true.

> which is not (as far as I know) subject to retroactive revision as a consequence of the vagarities of planetary or celestial motion

I'm afraid you are wrong on that. The unix time is synced with UTC. UTC has so called "leap seconds" scheduled at irregular intervals by the International Earth Rotation and Reference Systems Service to keep it in sync with the Earth's actual movements. So in effect the unix timestamp is wrangled to sync with the Earth's motion.

> if it is, I would be fascinated to know more

https://en.wikipedia.org/wiki/Unix_time#UTC_basis

https://en.wikipedia.org/wiki/Leap_second

Re: Time is an illusion, Unix time doubly so

#29

Post by epicide »

lazide wrote: post #26
mannykannot wrote: post #21

"On Unix systems we measure time as the number of seconds since "the epoch": 00:00:00 UTC on January 1st, 1970.... this definition is not based on something sensical such as, say, the objective frequency of vibration of a Cesium-133 atom, but on a convenient fraction of the time it takes a particular large rock to complete a full rotation around its own axis." Well, seconds have not been defined as "a convenient frac…

That’s a very recent change - and it’s not like 9192631770 transitions/hz (which is hilariously self referential!) is some obvious, natural value that ISN’T based on the historic ‘typical’ length of the day based on our rotation around the sun. A second being 1/86400th of a day (24 hrs * 60 minutes * 60 seconds per minute) is still essentially true, and based, essentially still on the seasons and our movement around…

> it’s not like 9192631770 transitions/hz ... is some obvious, natural value

No, but it is a phone number in the Raleigh area.

Re: Time is an illusion, Unix time doubly so

#30

Post by aumerle »

friendzis wrote: post #23
gjulianm wrote: post #16

Maybe 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.

> Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't. You cannot, by definition, tell how many Unix seconds later "third of may, 2025, at noon, local time" is - there is no way to convert future, local times to Unix times, because that "conversion code" is not fixed. Sure, we can reasonably expect that definition of time flow relationshi…

That's true regardless of how you choose to encode time and is a problem of local time zones not unix time.
Post reply on HN