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

211–220 of 333 posts

Re: 2038: Only 21 years away

#211

Post by leoedin »

dboreham wrote: post #48
jamoes wrote: post #26

Earlier quoted context omitted.

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

I'm not convinced that the problem was considered in those terms. Imagine that there was a meeting where someone said "I'm going to make time_t 64-bits because if I don't it will mean all software will break in unfortunate ways in the year 2038", and someone else said "Yeah, that's something to be concerned about but we can't do that because memory and disk space is at present too expensive to allow it". Well, I'm co…

Whenever I do embedded work with counters, every time I assign a variable that has a possibility of overflowing I do a little mental count about how likely it is to overflow. That's part of of the software development process.

They may not have had a meeting about it, but I think it's exceedingly unlikely that whoever decided to assign a 32 bit int to store time didn't give some consideration to the date range it could represent. Otherwise how would they know not to use a 16 bit int?

Re: 2038: Only 21 years away

#212

Post by M_Grey »

archgrove wrote: post #9
Aloha wrote: post #7

Earlier quoted context omitted.

There is a certain amount of snark embedded in this post, but its not a bad idea at all - I'll be in much the same boat at that time - perhaps I can borrow the same idea...

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…

Aren't you worried that by then someone will develop and train a DNN to do that?

Re: 2038: Only 21 years away

#213

Post by pinaceae »

OnACoffeeBreak wrote: post #197
pinaceae wrote: post #149

Earlier quoted context omitted.

you might be underestimating modern med devices which even have wireless access (beats a port or invasive surgery to read a log). example for the issues in this area: https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf

I see "wireless", but not "WiFi" or "802.11*" in the PDF. For what it's worth, devices I work on have a few wireless interfaces while guaranteeing 20-year life time: one interface is long-range (on the order of 10km), two are short range (on the order of a few mm). There is no way we can get to 20-year life time with doing WiFi (maintaining current battery size/capacity) for long'ish range and maybe not even BT for s…

yes - but this means there is more than a simple OS operating in those devices.

and just like any other IoT, using generic chips and stacks is cheaper.

run QNX or Linux on it and walk away.

there are DYI insulin pump monitors out there already that use Linux on RaspberryPi - see here: https://openaps.org/

Re: 2038: Only 21 years away

#214

Post by OnACoffeeBreak »

pinaceae wrote: post #213
OnACoffeeBreak wrote: post #197

Earlier quoted context omitted.

I see "wireless", but not "WiFi" or "802.11*" in the PDF. For what it's worth, devices I work on have a few wireless interfaces while guaranteeing 20-year life time: one interface is long-range (on the order of 10km), two are short range (on the order of a few mm). There is no way we can get to 20-year life time with doing WiFi (maintaining current battery size/capacity) for long'ish range and maybe not even BT for s…

yes - but this means there is more than a simple OS operating in those devices. and just like any other IoT, using generic chips and stacks is cheaper. run QNX or Linux on it and walk away. there are DYI insulin pump monitors out there already that use Linux on RaspberryPi - see here: https://openaps.org/

The microcontrollers on these devices don't have MMUs. There is typically not even a USB interface. The microcontroller is in deep sleep mode saving power 99.9% of the time. During that time only essential peripherals are powered on and no code is executing.

A RasPi has no chance of running for 20 years off a single A-size non-rechargeable non-serviceable battery.

Re: 2038: Only 21 years away

#215

Post by AnimalMuppet »

LoSboccacc wrote: post #22
ISL wrote: post #15

Earlier quoted context omitted.

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.

On mainframes, right? But Unix wasn't written to be a mainframe OS.

Re: 2038: Only 21 years away

#216

Post by elevensies »

DannyB2 wrote: post #155
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.

My retirement planning is to work on the Y10K problem. When the year 9997 comes along, everyone is going to start worrying about the rollover to five digit years. In about the year 9995 I will start seriously brushing up on my COBOL.

The only codebase I've checked personally can't handle Y10K, so there should be plenty of business: https://github.com/python/cpython/blob/6f0eb93183519024cb360...

Re: 2038: Only 21 years away

#217

Post by antirez »

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.

Pardon, it's billion indeed if you count seconds. I wrote millions for mistake, but thinking about it once you have 64 bits, milliseconds are nice to have...

Re: 2038: Only 21 years away

#218

Post by joshuaduffy »

bshimmin wrote: post #94
axlee wrote: post #78

Earlier quoted context omitted.

It was a good time to be a COBOL developer.

There's always someone on HackerNews who has done something pertinent to almost any discussion (it's one of the best things about being here, in fact) - are there any COBOL guys or gals who made a fortune fixing Y2K bugs who'd like to share their story?

I wasn't around then, but I've worked with many programmers who said: £1000 per day (at least) as a consultant (solo or sub)

Re: 2038: Only 21 years away

#219

Post by cpeterso »

DannyB2 wrote: post #155
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.

My retirement planning is to work on the Y10K problem. When the year 9997 comes along, everyone is going to start worrying about the rollover to five digit years. In about the year 9995 I will start seriously brushing up on my COBOL.

My bank's website allowed me to set a recurring monthly transfer until the year 9999.

The Long Now Foundation uses five-digit dates like 02017 in their work. :)

Re: 2038: Only 21 years away

#220

Post by sixdimensional »

On a side but related note, I don't understand why many programming languages and databases don't have a positive and negative infinity date placeholder/token value that is standardized and cross platform. Negative infinity date is "past", positive infinity date is "future". This would solve the common problem of what date to use when you are trying to talk about unknown date in the future or unknown date in the past, rather than using weird placeholders like 9999-12-31 or 1900-01-01 or other magic numbers.
Post reply on HN