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

61–70 of 104 posts

Re: Time is an illusion, Unix time doubly so

#61

Post by hinkley »

haberman wrote: post #55
a_shovel wrote: post #33

I'm still of the opinion that handling leap seconds by ignoring them is a dumb idea. Unix time should be a steady heartbeat counting up the number of seconds since midnight, January 1 1970. Nice, clean, simple. How you might convert this number into a human-readable date and time is out of scope/implementation-defined/an exercise for the reader/whichever variation of "not my problem" you prefer.

What is the actual benefit of this? The cost is that conversion to/from civil time is far more complicated, and worse, cannot be computed for future dates for which leap seconds have not yet been determined. I think that 86,400-second days with a 24-hour leap smear hits a sweet spot of utility and usability: https://developers.google.com/time/smear There are very few applications that will know or care that seconds g…

How many times a second do computers communicate notions of time between each other, versus to a human? We’re talking many orders of magnitude here, and inequalities like that always change the winning strategy.

Re: Time is an illusion, Unix time doubly so

#62

Post by wongarsu »

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 industrial equipment. But God have mercy on those that forget some systems.

Re: Time is an illusion, Unix time doubly so

#63

Post by jzl »

tonmoy wrote: post #43
jzl wrote: post #42

I was surprised to learn that Linux has a “2262 problem” because of 64-bit time being used to store nanoseconds rather than seconds. That seems like a huge problem without an easy solution either. Yes there are almost 250 years to fix it but it seems like surprisingly bad planning. In any case it’s an interesting thought exercise to imagine what the fix should be.

Why is it bad planning? I can’t think of a better alternate plan.

It’s bad planning because 64-bit time stamps were supposed to provide coverage for “22 times the expected lifetime of the universe”, but by being the only OS to use those 64 bits to count nanoseconds, they only bought a couple more bits over 32-bit timestamps. What they could have done differently is not used nanoseconds for the epoch counter. Milliseconds seem like they would have offered the perfect balance.

Re: Time is an illusion, Unix time doubly so

#64

Post by photochemsyn »

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 altitude the faster the satellite’s velocity and the bigger the time slowdown due to this effect. On the flip side, general relativity states that clocks run faster in lower gravitational field, so the higher the altitude, the bigger the speedup is."

> "Those effects are not even and depending on altitude one or the other dominates. In the demonstration below you can witness how the altitude of a satellite affects the dilation of time relative to Earth..."

There's also a nice if complex explanation of why your GPS receiever needs four satellite emitters to calculate the time bias of its clock.

Re: Time is an illusion, Unix time doubly so

#66

Post by marcosdumay »

wongarsu wrote: post #59
haberman wrote: post #55

Earlier quoted context omitted.

What is the actual benefit of this? The cost is that conversion to/from civil time is far more complicated, and worse, cannot be computed for future dates for which leap seconds have not yet been determined. I think that 86,400-second days with a 24-hour leap smear hits a sweet spot of utility and usability: https://developers.google.com/time/smear There are very few applications that will know or care that seconds g…

Skipping or smearing leap seconds means conversion to/from civil time is simple ... as long as you only want an accuracy of +-1 second. If you need better conversion, you have to know how the system chose to handle leap seconds. If it smears, you have to know and implement the smear algorithm, if it doesn't then some unix timestamps will map to two different points in civil time (second 59 and 60 in any hour with a l…

If you need better precision, you don't go converting to/from civil time, because people think on quanta of ~1 second and better precision is not defined there.

Instead, I'll put my rule here: It's perfectly reasonable to drop your time precision to ~1 second when converting it into "people time", and you should never expect better precision from a back conversion.

That's not saying you don't need TAI. It's just not reasonable to mix it and UTC et. al. If you need TAI, you live in TAI.

Re: Time is an illusion, Unix time doubly so

#67

Post by e12e »

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…

> 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

Re: Time is an illusion, Unix time doubly so

#68

Post by spirographer »

Loved the article! There are so many great details such as the standardization of UTC happening after UNIX time invented, UNIX itself being born before the epoch, and all the great insight into the morass of 64 bit time across modern OSes.

Putting on my pedantic hat though, I see that East and West were switched in the discussion of Japan's unique 50/60Hz AC frequency split, and I can't get my mind off it. Hope you can make the edit.

Re: Time is an illusion, Unix time doubly so

#69

Post by 10000truths »

Tuna-Fish wrote: post #40
a_shovel wrote: post #33

I'm still of the opinion that handling leap seconds by ignoring them is a dumb idea. Unix time should be a steady heartbeat counting up the number of seconds since midnight, January 1 1970. Nice, clean, simple. How you might convert this number into a human-readable date and time is out of scope/implementation-defined/an exercise for the reader/whichever variation of "not my problem" you prefer.

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

Applications that are require clock synchronization across multiple machines should be maintaining their own clock anyways, independent of the system clock. NTP for millisecond-order precision, atomic clock time cards for microsecond-order precision.

Re: Time is an illusion, Unix time doubly so

#70

Post by hinkley »

e12e wrote: post #67
hinkley wrote: post #60

Earlier quoted context omitted.

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…

> 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 drift. When the client is sending data such as a POST, it also sends a Date header. That can account for time zones, clock drift, and to an extent network latency. When you’re legally bound to establish the order of events in a distributed system someone has to be the source of truth, and even when you’re not it’s still good to have for your own purposes. The system of record is the only thing that is running on the same clock as the system of record, so it is the most sensible source of truth.

So when a client sends you a buffer full of dated events, you can (and should) consider the timestamps in the POST body as relative to the Date header, not your local system time. Otherwise someone running on brown power or old school power saving mode will screw up all of the timelines in your data.

Post reply on HN