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

241–250 of 333 posts

Re: 2038: Only 21 years away

#241

Post by sedachv »

drzaiusapelord wrote: post #110
archgrove wrote: post #9

Earlier quoted context omitted.

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see…

>verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. The problem with mainframes is that they can't be trivially upgraded or migrated to 64-bit like modern OS's on x86 hardware can be. Vendor lock-in, retirement of OS, bare to the metal coding, etc caused this. If these mainframes were running a modern OS, it would have been trivial to upgrade them to a 64-bit versi…

Pretty much everything in your post is wrong. IBM mainframes are heavily virtualized and have very good support for moving to larger address spaces. VM and MVS moved from 24-bit to 31-bit to 64-bit address spaces. You can run the old 24-bit applications and upgrade them as needed. Even assembly programs - the old assemblers and instructions are supported on newer hardware. System i (System/38-AS/400) was built around a 128-bit virtual address space from the start. There is much more support for fixing old software on mainframes than there is for proprietary 1980s-era PC and Unix applications.

I have no idea why you think running 32-bit today is "odd." 32-bit desktops and small servers are still perfectly usable today. 32-bit microcontrollers are going to be around for a very long time (just look at how prevalent the 8051 remains), and a lot of them are going to be running Linux. It also makes a lot of sense to run 32-bit x86 guests on AMD64 hypervisors - your pointers are half the size so you can get a lot more use out of 4GiB of memory.

Re: 2038: Only 21 years away

#242

Post by joepvd »

5ilv3r wrote: post #233
dboreham wrote: post #35

Earlier quoted context omitted.

I'm nearly old enough to try to put my brain back to that time (I used Unix V7 on a PDP-11/45..) and I'm not sure the replies here are quite on the mark. Yes, if someone had suggested a 64-bit time_t back then, the obvious counterargument would have been that the storage space for all time-related data would double and that would be a bad thing. Also true that there was no native language support for 64-bit ints, but…

This is a great point. Time synchronization between systems that do not share a clock line is a pretty recent thing. It didn't used to matter at all if your clock was wrong, and many people would never notice or bother to fix it. Now if your clock is wrong you can't even load anything in a web browser. Your clock sync daemon has to fix your clock before the certs will be accepted as valid. HTTPS is a bummer, maaan.

You have a reference for HTTPS problems with skewed client time?

Re: 2038: Only 21 years away

#243

Post by caf »

smsm42 wrote: post #199
legulere wrote: post #119

Earlier quoted context omitted.

The year 2038 problem is actually younger than unix. The first definition was 60th of seconds since 1970-01-01T00:00:00.00 stored in two words (note that a word is 18 bit on a PDP-7!). That definition was later changed. Also Linus could have defined `time_t` to be 64 bit when he started linux. https://en.wikipedia.org/wiki/Unix_time#History http://aaroncrane.co.uk/2008/02/unix_time/

I'm not even sure there was a standard 64-bit type for C in 1991... Or how well compiles on PC would support that.

There wasn't - the largest minimum integer size from C90 (ANSI C) was long, with at least 32 bits. "long long" was agreed upon at an informal summit in 1992 as an extension 64 bit type on 32 bit systems until it was standardised in C99 (but already existed in several compilers at that point, including GCC).

So GCC may have had 'long long' already when Linus started working on Linux.

Re: 2038: Only 21 years away

#244

Post by paxswill »

Newton (Apple's old PDA) had a similar problem in 2010 [0]. In short, while the base system and C++ interfaces used 32-bit unsigned ints with a base of 1904-01-01, NewtonScript uses 30-bit signed ints, with a working base of 1993-01-1, overflowing in 2010. The fix was a binary patch that changed the time bases.

0: http://40hz.org/Pages/Newton%20Year%202010%20Problem

Re: 2038: Only 21 years away

#245

Post by gravypod »

smsm42 wrote: post #199
legulere wrote: post #119

Earlier quoted context omitted.

The year 2038 problem is actually younger than unix. The first definition was 60th of seconds since 1970-01-01T00:00:00.00 stored in two words (note that a word is 18 bit on a PDP-7!). That definition was later changed. Also Linus could have defined `time_t` to be 64 bit when he started linux. https://en.wikipedia.org/wiki/Unix_time#History http://aaroncrane.co.uk/2008/02/unix_time/

I'm not even sure there was a standard 64-bit type for C in 1991... Or how well compiles on PC would support that.

Well when you're the only person/people using C you can get anything through the compiler committee very quickly.

Re: 2038: Only 21 years away

#246

Post by toast0 »

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

How many of the other data structure choices that were made in the early 1970s didn't need to be changed for 40 years or so?

A choice that gets you 40 years down the road, instead of millions of years down the road is a good choice, when you don't even know if you're going to have roads in 40 years.

Re: 2038: Only 21 years away

#247

Post by sedachv »

antirez wrote: post #24

Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.

That is actually how Common Lisp represents time:

https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo...

When you look up "integer": https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo...

"An integer is a mathematical integer. There is no limit on the magnitude of an integer."

What happens when an integer overflows from a fixnum (single-word representation) is that it gets upgraded to a bignum behind the scenes.

IMO Common Lisp is the only programming languages that handles time correctly out of the box, and aside from Scheme (http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z...), is the only programming language with proper support for numbers.

Re: 2038: Only 21 years away

#248

Post by placeybordeaux »

Nition wrote: post #200
hunterjrj wrote: post #84

Earlier quoted context omitted.

Up vote for the Deepness reference! What a great novel, and I suspect the concept of a "programmer archaeologist" would be of interest to many here...

A Fire Upon The Deep is a fantastic book as well.

I loved both of these, any recommendations for other similar books?

Re: 2038: Only 21 years away

#249

Post by mikeash »

ufo wrote: post #239
mikeash wrote: post #65

Earlier quoted context omitted.

If you told the original UNIX developers that there was even the slightest chance their system might still be in use in 2038, they probably would have called in some large, friendly men in white coats to haul you away. Add to that the fact that memory was very much not cheap at the time. Memory for the PDP-7 (the first computer to run UNIX) cost $12,000-20,000 for 4kB of memory. In 1965 dollars. In 2017 terms, that m…

Wouldn't it actually be 10 to 20 dollars per instance instead of hundreds of dollars?

$10-20 would be the raw cost at the time, not accounting for inflation. I think I double-counted the four bytes, because in 2017 dollars it would be about $80-160, not $300+.

Re: 2038: Only 21 years away

#250

Post by flukus »

janwillemb wrote: post #95
axlee wrote: post #78

Earlier quoted context omitted.

It was a good time to be a COBOL developer.

I never quite understood why the transition from 1999-2000 should be a big deal for a computer system, until I learned about how COBOL works: it stores numbers as its string-representation unless told otherwise, and trying to store 100 in a field of two bytes will happily be stored as "00". Of course we had other bugs, with the same cause, well after the y2k-period.

It's not just cobol, there are still plenty of devs out there storing dates as strings. Aside from using more space, most won't notice until the try and filter on a date range.
Post reply on HN