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

71–80 of 104 posts

Re: Time is an illusion, Unix time doubly so

#71

Post by mjevans »

wongarsu wrote: post #62
mlichvar wrote: post #53

The article missed an opportunity to describe how spectacularly can things break when the 32-bit time_t overflows in Y2038. If you still have such a machine (preferably without any valuable data), try setting the date right before the overflow with this command date -s @$[2**31 - 10] and see if you can recover the system without reboot. I have seen different daemons stopped responding and just consuming CPU, NTP clie…

Factories are full with machines that get replaced every couple decades, and that run software setups even older. Roughly a decade ago I was involved in the development of an embedded system for industrial use, and the approach to Y2038 was "doesn't matter, I'll be retired by then". The system is still sold. I wouldn't be surprised if a lot of companies will handle it by just setting the clocks back 50 years or so on…

Most of these systems probably don't even care about the real time... so it'd just be more effective to map them back to a different index and handle it with an offset externally.

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

At a glance it looks like 1971 and 1993 might be good alternatives for 2038. The command line cal program agrees with where dates start each month for all three years.

Re: Time is an illusion, Unix time doubly so

#72

Post by seanc »

photochemsyn wrote: post #64
seanc wrote: post #12

From 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 bett…

For even more fun, take a look at this excellent post on GPS, and in particular, the time problem: https://ciechanow.ski/gps/#time > "When it comes to the flow of time on those satellites, there are two important aspects related to Einstein’s theories of relativity. Special relativity states that a fast moving object experiences time dilation – its clocks slow down relative to a stationary observer. The lower the alt…

What a find! That's a top notch GPS explanation; simple, detailed and great visualization of complex stuff. Thanks!

Re: Time is an illusion, Unix time doubly so

#74

Post by russellbeattie »

lproven wrote: post #41
senko wrote: post #8

ICYMI: The title is a reference to The Hitchhiker's Guide to the Galaxy: https://en.m.wikipedia.org/wiki/The_Hitchhiker%27s_Guide_to_... ("time is an illusion, lunch time doubly so")

There are multiple HHGTTG references in it, as is the author's Twitter bio: > Vell, I'm just zis guy, you know? (A quotation from Gag Halfrunt, Zaphod Beeblebrox's "personal brain care specialist".)

≥ that represents a date around 292 billion years in the future, or roughly 22 times the estimated age of the universe, and thus officially Somebody Else's Problem.

And another... (Also, given Adams wrote a few Dr. Who episodes, one which turned into Life, the Universe and Everything, the "Time Lords" reference could be another.) The "Oh, and one more thing" is a slight misquote of, "And another thing."

As DNA is my favorite author bar none, I like this post a lot.

Re: Time is an illusion, Unix time doubly so

#75

Post by masklinn »

hinkley wrote: post #70
e12e wrote: post #67

Earlier quoted context omitted.

> The HTTP 1.0 spec already had a solution for two machines with different ideas of the current date. I can't recall noticing this, and can't seem to find anything about it in[1] - could you elaborate? [1] https://www.w3.org/Protocols/HTTP/1.0/spec.html#Date

You’ve found it, or very nearly. The very next section is Expires: > The format is an absolute date and time as defined by HTTP-date in Section 3.3. The implication is subtle but critical. When the server sends a Date header and an Expires header, you don’t expire the content when the local time exceeds the Expires Header. You expire it at LocalTime + (Expires - Date) That covers not only time zones but also clock dr…

> You expire it at LocalTime + (Expires - Date)

Which makes for a wonky mess, and I guess is why Cache-Control did away with the entire thing and just tells you how long the response is fresh.

Re: Time is an illusion, Unix time doubly so

#76

Post by alvarlagerlof »

seanc wrote: post #72
photochemsyn wrote: post #64

Earlier quoted context omitted.

For even more fun, take a look at this excellent post on GPS, and in particular, the time problem: https://ciechanow.ski/gps/#time > "When it comes to the flow of time on those satellites, there are two important aspects related to Einstein’s theories of relativity. Special relativity states that a fast moving object experiences time dilation – its clocks slow down relative to a stationary observer. The lower the alt…

What a find! That's a top notch GPS explanation; simple, detailed and great visualization of complex stuff. Thanks!

Check out the rest of the site

Re: Time is an illusion, Unix time doubly so

#77

Post by masklinn »

mjevans wrote: post #71
wongarsu wrote: post #62

Earlier quoted context omitted.

Factories are full with machines that get replaced every couple decades, and that run software setups even older. Roughly a decade ago I was involved in the development of an embedded system for industrial use, and the approach to Y2038 was "doesn't matter, I'll be retired by then". The system is still sold. I wouldn't be surprised if a lot of companies will handle it by just setting the clocks back 50 years or so on…

Most of these systems probably don't even care about the real time... so it'd just be more effective to map them back to a different index and handle it with an offset externally. https://en.wikipedia.org/wiki/Doomsday_rule At a glance it looks like 1971 and 1993 might be good alternatives for 2038. The command line cal program agrees with where dates start each month for all three years.

Fwiw, https://en.wikipedia.org/wiki/Perpetual_calendar

Re: Time is an illusion, Unix time doubly so

#78

Post by hinkley »

masklinn wrote: post #75
hinkley wrote: post #70

Earlier quoted context omitted.

You’ve found it, or very nearly. The very next section is Expires: > The format is an absolute date and time as defined by HTTP-date in Section 3.3. The implication is subtle but critical. When the server sends a Date header and an Expires header, you don’t expire the content when the local time exceeds the Expires Header. You expire it at LocalTime + (Expires - Date) That covers not only time zones but also clock dr…

> You expire it at LocalTime + (Expires - Date) Which makes for a wonky mess, and I guess is why Cache-Control did away with the entire thing and just tells you how long the response is fresh.

Not as wonky as you'd think, and 60 minutes means something much different than 12:15. Which can be good and it can be bad, but many of my experiences with TTLs have not been pleasant. 60 minutes, as typically implemented, means some user out there has data that is 1:58 stale and he's yelling at your boss on the phone who is now trying to figure out if he should be passing the favor along.

See also ETags which stop trying to be clever about dates and instead be clever about the contents of the message.

Why I like the Date header is that it works well with REST endpoints that care about time but for whom caching is either not a good idea or is orthogonal.

Re: Time is an illusion, Unix time doubly so

#79

Post by nrvn »

From Beat The Devil (1953):

Time. Time. What is time? Swiss manufacture it. French hoard it. Italians squander it. Americans say it is money. Hindus say it does not exist. Do you know what I say? I say time is a crook.

Re: Time is an illusion, Unix time doubly so

#80

Post by dhosek »

hinkley wrote: post #60
Tuna-Fish wrote: post #40

Earlier quoted context omitted.

> Unix time should be a steady heartbeat counting up the number of seconds since ... This is nice and clean, so long as you have exactly one computer. The second there are more than one, and they are talking to each other, their clocks can go out of sync with each other. And they will, because they are physical systems that are imperfect and in general much less precise than you'd expect them to be. This means that t…

I think people forget how often computers in the 80’s and 90’s were turned off, keeping track of time with a backup battery, and just how many machines had a dead backup battery and users that didn’t know any better. I fielded tech support questions from an app that had grown to send email. Every week we got a couple of emails from some time on January 1, 1970, each from a new person, and a whole slew of people whose…

There was a Cray installation in Japan in the late 80s or early 90s which was reportedly turned off at night to save electric costs.
Post reply on HN