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

2038: Only 21 years away

lwn.net

Post reply on HN
Print view View original

21–30 of 333 posts

Re: 2038: Only 21 years away

#21

Post by drzaiusapelord »

beagle3 wrote: post #13
_uhtu wrote: post #5

Is there a reason why they decided to store time as seconds from 1970? In a 32-bit integer nonetheless. It seems like basic logic would have lead the original designers to make it at least 64 bits so that you'd never overflow it (with a 64 bit time we'd be good til the year 292277026596). 64 bits would also allow you to also cover the entirety of history, all the way back to 13.7 billion years ago when the Universe c…

Back in 1970, no language had a 64-bit integer type. And it started with Unix, which was a skunkworks hobby project, so a thinking of "we'll solve it within the next 68 years" is perfectly reasonable. They could have made it unsigned instead of signed, which would have made it work until 2100 or so, but I think a 68-year horizon is more than most systems being built today have.

If anything I imagine guys like Ritchie never thought we'd be using a Unix-based system so far in the future. Back then OS's were a dime a dozen and the future far too cloudy to predict in regards to computing.

>but I think a 68-year horizon is more than most systems being built today have.

That's a lot of time, especially if we see Linux breaking into the mainstream about 1995 or so. That's 43 years to worry about this. Meanwhile, we saw Microsoft break into the mainstream at around 1985, which only gave us 15 years to worry about Y2K.

Re: 2038: Only 21 years away

#22

Post by LoSboccacc »

ISL wrote: post #15
_uhtu wrote: post #5

Is there a reason why they decided to store time as seconds from 1970? In a 32-bit integer nonetheless. It seems like basic logic would have lead the original designers to make it at least 64 bits so that you'd never overflow it (with a 64 bit time we'd be good til the year 292277026596). 64 bits would also allow you to also cover the entirety of history, all the way back to 13.7 billion years ago when the Universe c…

https://en.wikipedia.org/wiki/Intel_8086 In the late 1970s, the cutting-edge microprocessor was 16-bit. The first 32-bit Intel chip was the 386, which debuted in 1985. The TRS-80, a common small computer in the late 70s, offered 4kb-48kb of RAM. When using hardware with that capacity, overflowing time_t in 2038 is hardly a concern.

IBM ran 128 bit virtualized architecture on top of 1988 chips.

Re: 2038: Only 21 years away

#23

Post by btilly »

lazyjones wrote: post #19

Meh, we'll just redefine time_t as (signed) seconds since 2000 or so and subtract 30 years in seconds from all timestamps ... ;-)

No, you make it time_t (unsigned) seconds since the epoch. That pushes the problem out 70+ years and doesn't break any binary APIs.

Re: 2038: Only 21 years away

#25

Post by chiph »

archgrove wrote: post #3

This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.

There were fortunes made in 1999 doing similar work.

Re: 2038: Only 21 years away

#26

Post by jamoes »

_uhtu wrote: post #5

Is there a reason why they decided to store time as seconds from 1970? In a 32-bit integer nonetheless. It seems like basic logic would have lead the original designers to make it at least 64 bits so that you'd never overflow it (with a 64 bit time we'd be good til the year 292277026596). 64 bits would also allow you to also cover the entirety of history, all the way back to 13.7 billion years ago when the Universe c…

The reasoning I've heard is that back then memory and disk space were limited and they couldn't sacrifice the extra bytes.

For example, if every file stores three timestamps (mtime, ctime, and atime), then that's an extra 12 bytes per file to store a 64 bit timestamp vs a 32 bit timestamp. If your system has five thousand files on it, that's an extra 60 KB just for timestamps. In 1970, RAM cost hundreds of dollars per KB [1], so this savings was significant.

[1] http://www.statisticbrain.com/average-historic-price-of-ram/

Re: 2038: Only 21 years away

#27

Post by gbrown_ »

> statx() will serve as the year-2038-capable version of the stat() family of calls

Does this seem horrible to anyone else? Why not fix stat()? Does this syscall have to be so highly preserved even when it will be broken?

One of the advantages of the OpenBSD approach of being able to make intrusive changes saw their time_t made 64-bit in the 5.5 release in 2014.

https://www.openbsd.org/55.html

Admittedly this is much harder for Linux as they can't make the change an verify in a single place due to the separation of kernel and userland/ the fact Linux has many distros.

Re: 2038: Only 21 years away

#28

Post by iamgopal »

Call me stupid, but I think computing will be much different to worry about this. ( single chip os or iot to the level that each hardware component is separate, or something else...)

Re: 2038: Only 21 years away

#29

Post by gregmac »

I wonder how much attention this will get from the general public and non-technical managers? After all, programmers predicted doom for Y2k, and then "nothing happened".

This is almost the same situation, except I assume slightly less understandable to a non-programmer (you have to understand seconds-since-1970 and why we'd do that instead of storing the date as text, powers of 2 and the difference between 32 and 64-bit).

Re: 2038: Only 21 years away

#30

Post by simias »

btilly wrote: post #23
lazyjones wrote: post #19

Meh, we'll just redefine time_t as (signed) seconds since 2000 or so and subtract 30 years in seconds from all timestamps ... ;-)

No, you make it time_t (unsigned) seconds since the epoch. That pushes the problem out 70+ years and doesn't break any binary APIs.

Changing from signed to unsigned is very much an ABI break.
Post reply on HN