Heater
Posts: 9686
Joined: Tue Jul 17, 2012 3:02 pm

2038 bug(s)

Thu Apr 21, 2016 7:06 pm

A recently closed thread brought up an issue due to the way Unix handles time. In that case it was to do with before time began, before 1st Jan 1970.

At the other end of the scale Unix time runs out at 03:14:07 UTC on 19 January 2038.

See here for details: https://en.wikipedia.org/wiki/Year_2038_problem

This may seem far away but this issue already bit me a few years ago.

I was creating self-signed certificates for a VPN. They did not work. There was no clear error logged as to why.

Recently I found out it was because I had set the expiry time to something well past 2038. Turns out that on 32 bit machines openssl overflowed somewhere and things went wrong. (This issue has been fixed in openssl as far as I can tell)

Just thought I'd mention it.

shuckle
Posts: 565
Joined: Sun Aug 26, 2012 11:49 am
Location: Finland

Re: 2038 bug(s)

Thu Apr 21, 2016 7:14 pm

good reason to upgrade to 64 bit?

Heater
Posts: 9686
Joined: Tue Jul 17, 2012 3:02 pm

Re: 2038 bug(s)

Thu Apr 21, 2016 7:36 pm

Well, in the case of my certificate creation problem if I had used a 64 bit machine there would have been no problem.

In general though this can be a software issue. What if you database has been storing dates in 32 bits since forever?

W. H. Heydt
Posts: 8768
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: 2038 bug(s)

Thu Apr 21, 2016 7:55 pm

Heater wrote:Well, in the case of my certificate creation problem if I had used a 64 bit machine there would have been no problem.

In general though this can be a software issue. What if you database has been storing dates in 32 bits since forever?
Look for a database update that moves to 64 bit date formats. (And change your programs to agree with that.)

The most general solution (and it would have to be done as general system change) would be to define a 'date' datatype (which, if I'm not mistaken has been done). The next step would be to ensure that all compilers generate such variables as being larger than 32 bits. Over time, as applications code gets re-compiled, all dates will be longer than 32 bits.

You are correct that NOW is a good time to start that process.

hippy
Posts: 3570
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: 2038 bug(s)

Thu Apr 21, 2016 8:03 pm

Heater wrote:In general though this can be a software issue. What if you database has been storing dates in 32 bits since forever?
This ^

It's not so much what the hardware architecture is - 64-bit and larger numbers can be handled by even a 1-bit architecture - nor how the chip, OS or API handles things. It's how the application code handles it. If the code expects time to fit in a 32-bit entity, there is a problem when it won't.

And it is not just Linux which is affected. Anything which has a 'from some epoch' time will fail once that time exceed the size of the thing it is being stored in.

Even if one moves to 64-bit there will still be a problem in the future. A long time off admittedly. But it's that 'too far away to worry about' and 'this code won't be running then anyway', which gets us into a mess in the first place. I agree; 64-bit data is the fix, for now. But it's not the perfect fix; it's just batting the problem far enough into the future that we don't care. Philosophically, if we are learning anything, we shouldn't be repeating the mistakes of the past.

Heater
Posts: 9686
Joined: Tue Jul 17, 2012 3:02 pm

Re: 2038 bug(s)

Thu Apr 21, 2016 8:48 pm

hippy,

Wait a minute, the maximum positive number you can represent in a signed 64 bit integer is 9223372036854775807

The age of the universe so far is 13.82 billion years (give or take a bit). I make that about 435827520000000000 seconds.

Dividing these I get about 21.

That is to say that a 64 bit seconds counter is good for 20 odd times the age of the universe so far.

I'm not about to lose any sleep over that limitation :)

asandford
Posts: 1999
Joined: Mon Dec 31, 2012 12:54 pm
Location: Waterlooville

Re: 2038 bug(s)

Thu Apr 21, 2016 9:12 pm

hippy wrote: And it is not just Linux which is affected. Anything which has a 'from some epoch' time will fail once that time exceed the size of the thing it is being stored in.
Indeed. Arduino millis() roll over every ~49 days

User avatar
jackokring
Posts: 815
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: 2038 bug(s)

Fri Apr 22, 2016 4:47 pm

Maybe a new system call epoch()? Well at least people could start using it now if it returns 0, and 32/64 bit would not matter.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

jahboater
Posts: 2851
Joined: Wed Feb 04, 2015 6:38 pm

Re: 2038 bug(s)

Tue Apr 26, 2016 10:39 pm

hippy wrote:
Heater wrote:Even if one moves to 64-bit there will still be a problem in the future. A long time off admittedly. But it's that 'too far away to worry about' and 'this code won't be running then anyway', which gets us into a mess in the first place. I agree; 64-bit data is the fix, for now. But it's not the perfect fix; it's just batting the problem far enough into the future that we don't care. Philosophically, if we are learning anything, we shouldn't be repeating the mistakes of the past.
Wait a minute, the maximum positive number you can represent in a signed 64 bit integer is 9223372036854775807
If anyone wants to wait for it, 64-bit time_t will fail at 15:30:08 on Sunday, 4 December 292,277,026,596 - approximately 292 billion years from now.

paulie
Posts: 260
Joined: Thu Jan 19, 2012 6:51 pm

Re: 2038 bug(s)

Tue Apr 26, 2016 11:32 pm

The Sun will become a Red Giant in about 5 billion years: all life larger than a single cell will be killed off rapidly as the oceans boil away.
Extremophiles will last a bit longer.

We'd better start working on those faster-than-light starships pretty soon....
It has been my custom to use Xeyes

User avatar
MarkHaysHarris777
Posts: 1820
Joined: Mon Mar 23, 2015 7:39 am
Location: Rochester, MN
Contact: Website

Re: 2038 bug(s)

Tue Apr 26, 2016 11:45 pm

Ladies and gentlemen, its only 22 years away... and stuff is going to start breaking before it gets here... and 64 bit architecture is not going to cut it; no way.

Global governments need to be working on two problems right now 1) global climate shift (or whatever you want to call it, its REAL... and 2) the 2038 problem ITS REAL TOO... and neither one is going away on its own...

So, when it gets here (should I live so long, Lord willing) I'm just going to slide my puck across that shuffle board and laugh my @ss off.

Hint: ... we need to get started now.
marcus
:ugeek:

asandford
Posts: 1999
Joined: Mon Dec 31, 2012 12:54 pm
Location: Waterlooville

Re: 2038 bug(s)

Tue Apr 26, 2016 11:51 pm

MarkHaysHarris777 wrote:Ladies and gentlemen, its only 22 years away... and stuff is going to start breaking before it gets here... and 64 bit architecture is not going to cut it; no way.

Global governments need to be working on two problems right now 1) global climate shift (or whatever you want to call it, its REAL... and 2) the 2038 problem ITS REAL TOO... and neither one is going away on its own...

So, when it gets here (should I live so long, Lord willing) I'm just going to slide my puck across that shuffle board and laugh my @ss off.

Hint: ... we need to get started now.
You have more pressing needs, such as trump or clinton as POTUS

plugwash
Forum Moderator
Forum Moderator
Posts: 3245
Joined: Wed Dec 28, 2011 11:45 pm

Re: 2038 bug(s)

Wed Apr 27, 2016 12:15 am

The problem is that time_t is part of the libc and kernel ABIs. In particular time_t is used in a number of structs which pass from userland apps through libc and into the kernel. So changing it without breaking all existing binaries is hard. Some work has started on the kernel side, i'm not aware of anything goin on on the libc side..

And it's an open question whether there will still be widespread usage of general purpose 32-bit linux systems (i.e. systems where people actually care about binary compatibility) in 2038.

http://www.theregister.co.uk/2015/02/20 ... 8_problem/

There is some progress though.

http://www.sourceware.org/ml/libc-alpha ... 00893.html

BMS Doug
Posts: 3824
Joined: Thu Mar 27, 2014 2:42 pm
Location: London, UK

Re: 2038 bug(s)

Wed Apr 27, 2016 7:34 am

Heater wrote:At the other end of the scale Unix time runs out at 03:14:07 UTC on 19 January 2038.

This may seem far away but this issue already bit me a few years ago.

I was creating self-signed certificates for a VPN. They did not work. There was no clear error logged as to why.
I've also been bitten by this bug,
I was investigating why an Air Handling unit (AHU) wasn't running and found that the timeschedule within the BACNET controller had expired (the timeschedule was within occupancy but its authoriasation period had run out).
I extended the authorisation period for some arbitrary far future date and it wouldn't take it, I ended up setting it to 2036 and assuming that the building would be someone else's problem before then (it will probably have been demolished and a new one erected, if not then it will have an urgent need for a new BMS system).
Doug.
Building Management Systems Engineer.

Return to “Off topic discussion”

Who is online

Users browsing this forum: No registered users and 4 guests