Jump to content
bigdaddy

2038

Recommended Posts

Hi everyone,

 

Here's a discussion for everyone, particularly if you are computer orientated...

 

Does anyone remember the hype around the year 2000?...The "milleum bug" ? And the names of the like?

 

Issues surrounding the change of the dates when the millenium changed certainly needed to dealt with..And they were

 

How about the issues surrounding the date coding with 2038? ...The talk ATM is, these issues promise to be larger than the issues with the year 2000 change...

 

Anyone want to talk further about this?...

 

Cheers.

 

 

Share this post


Link to post
Share on other sites

Isn't 2038 the Unix bug? IIRC in computer circles it was talked about as being more serious than the PC version (Y2K) simply because far more critical systems are on Unix. It's to do with the number of seconds since 1970 I think.- 2^31 being 68+ years so 2038 is when the sign changes and it's suddenly 1970 - 68+ years (i.e some time in 1901.

 

Potentially far more serious than Y2K simply because all kinds of critical systems will be affected. You can imagine how much the banksters will squeal about having to employ programmers etc - they won't want to be spending 0.0000001% of their expected profits (per week by the time 2038 comes around) and so we will all have to pay more.

 

Don't tell Mr Rabbit - he'll start taxing us now so the banksters aren't out of pocket. :D

Share this post


Link to post
Share on other sites

As I understand it, in most cases, an OS patch will be able to deal with this issue.  It seems the primary concern is for really old legacy machines that are still in use (there are plenty out there) that use older OS's and custom OS's that are no longer in active production, which will require special code work on a project by project basis.  A lot of embedded OS devices could potentially have issues too unless they are capable of being reflashed with a patched OS or can receive a new ROM chip with an updated 2038 friendly OS.

 

To test this out on your own computer, you can simply set the BIOS clock (or system clock) to 10 minutes or so before January 19, 2038 3:14:08 (the actual "end time" to the second), boot it up and watch what happens. ;)

Share this post


Link to post
Share on other sites

My Belkin modem/router stubbornly insists the date is 1/1/1970 - even with NTP enabled.Also, on the website I'm setting up, my user account has been active for 44 years. (I was a prodigy, OK? :D Wait till you see how long I've been active on the net when it flips... :D)

Share this post


Link to post
Share on other sites

The trouble is somebody has to pull the trigger and decide on the new standard before software that counts the seconds can convert to it. interaction between databases (like online....um , everything) and other software that calculates a date needs to be consistent.

 

Just going to a 64 bit count would give us millions of years but it would also make for slow calculation. The suggestion that we adopt 64 bit data and count the milliseconds from year 0000 giving us about 300,000 years and speedy calculations makes sense to me.

 

But what do I know, I cant even get my shirt on the right way some mornings.

Share this post


Link to post
Share on other sites

I can chime in a little here as a software developer.  The 2038 bug is due to a certain way, and now de-facto standard, that many computers store and perform date calculation.  Not all software stores dates this way, but many times as a programmer, you convert dates to timestamps to perform date manipulation on them since working with timestamps are pretty easy.

 

What is a timestamp?  Like previously mentioned, it is the number of seconds since January 1, 1970 at midnight. Next, what are bits? Computers work at the level of bits.  A bit represents an electrical polarity, an on/off state, open closed state, or some kind of duality at the hardware level.  They get translated into binary as zero or one.  When sombody refers to something as being "8 bits" or "16 bits" 32, 64, etc... this means that the thing which they are referring is capable of handling 8, 16, 32, or 64 binary digits at a time.  32 bits means a succession of 32 zeros and ones.

 

Now, binary gets translated into different bases.  Computers don't handle base 10 natively.  All numbers like "12345", "20,000" "1970" etc...are represented by a string of binary digits.  Always.  Plus, there is sometimes another bit or binary digit that represents the sign of the number (-1970 vs 1970). 

 

So herein lies the problem.  The number of seconds from Jan 1 1970 00:00:00 until 3:14:07 AM GMT on January 19,2038,(according to y2038com) will take up more than 32 binary digits to store.  The reason is when you convert the base 10 seconds value to binary, plus sign, you get greater then 32 binary digits... I didn't do the calculation, but it is probably at that point that you roll over and get 33 digits. So a computer that has a 32 bit CPU could never represent a date greater than this value using the traditional signed timestamp.  Luckily, we have 64 bit computers now that can natively handle, at the CPU level, 64 binary digits at a time.  The problem is that, due to historical context, most programming constructs expect the timestamp to be a signed 32 bit integer.  The good news is that this can be changed easily.  A 64 bit integer can easily hold a 32 bit integer in it, so it could represent all previous dates plus more.  The previous poster said millions of years. 

 

 

Referencing http://www.y2038.com/, t

Share this post


Link to post
Share on other sites

The previous poster said millions of years. 

 

according to wika...thingy

 

approximately 292 billion years from now, at 15:30:08 on Sunday, 4 December 292,277,026,596 for a 64 bit unix second, that is proper overkill. 20 times the life of the current universe according to them!

 

the network protocol time end date in 2036 is already worked around because network time is adjusted relative to the clock servers on the network (as long as it is within 68 years of the correct date) so manufacturers install a current date into the rom and not an epoch start date or a use a battery backup.

Edited by yahoo2 (see edit history)

Share this post


Link to post
Share on other sites

292 billion years.  rofl.  OK then!

 

The issue still remains of code that works with 32 bit timestamps.  I find myself doing it all the time (should I still be doing this?).  A quick fix would be to implement 64 bit timestamp structures so that the ints would not overflow.  Ok, so I say "the solution" but I really don't know the overall implications of doing that.  In fact, I probably won't think much more of it for a while. My mind is on fish, plants and birds at the moment. :)

As for NTP, I'l take your word on it.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...