Jump to content

Year 2038 Problem


vipejc

Recommended Posts


Since Windows NT, including XP, use a 64-bit time integer for file and system time, are all programs for them safe from the Y2K38 problem?

Well, in the next 27 years this should become clear enough. :angel

But are you sure that in 2038 you will use a NTFS filesystem and/or a NT based system released some 30 years before?

(Please raise your hand you peeps that run on a daily basis a CP/M machine.)

The issue is known:

http://en.wikipedia.org/wiki/Year_2038_problem

it mainly affects Unix based OS (and conversely POSIX times)

There are a couple places dedicated to this issue:

http://www.deepsky.com/~merovech/2038.html

http://www.codeproject.com/KB/bugs/The-Year-2038-Bug.aspx

http://www.exit109.com/~ghealton/y2k/yrexamples.html

In non-critical apps/OS/systems, in 2038 we will be able to use SETBACK approach:

http://www.exit109.com/~ghealton/y2k/yrexamples.html#_OtherBad.WorkAround

And "proper" NT is immune:

http://www.exit109.com/~ghealton/y2k/yrexamples.html#_Native.Microsoft.Epochs

1601	Microsoft NT/2000 (Win32)	n/a	100nsec ticks since 1601-January-01 for a range of about 29,200 years

until roughly year 30,800 :w00t:

http://www.exit109.com/~ghealton/y2k/yrexamples.html#_Native.Microsoft.Ticks

though "bad" programs may still behave "wrongly".

jaclaz

Link to comment
Share on other sites

My BIOS' date goes all the way to 2099. I will have my 32-bit Windows XP Home w/ SP3 CD placed in my cold, dead hands before the lid to my coffin is closed and I am lowered into the ground. :yes:

Link to comment
Share on other sites

I'm positive. Enjoy your Windows 25 with space communication. :hello:

You probably misunderstood. :unsure:

I know that in year 2038 - if still alive - I will most probably be still using 2K (or in the worst case XP).

I was asking about you. :whistle:

And @Tripredacus ;), most probably we will be using Qemu 217.2 on an Ubuntu 408.25 "Wild Worry-free Wooing Wombat" with kernel 118.4.10 in order to run it on the AMINTEL i4886 1024bit processor.

And of course should not skynet gain self-awareness in the meantime. :ph34r:

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

And @Tripredacus ;), most probably we will be using Qemu 217.2 on an Ubuntu 408.25 "Wild Worry-free Wooing Wombat" with kernel 118.4.10 in order to run it on the AMINTEL i4886 1024bit processor.

I'd expect (presuming Microsoft was telling the truth) that I'd still be using Windows 8 x128 by 2038. Only because the "idea" of having a PC with an exabyte of RAM is such a mind-boggling yet fascinating idea. And to add in the fact that it would likely take me 25 years to save up enough money to buy that much RAM... Or at least a motherboard with 1 billion RAM slots on it. :w00t:

Link to comment
Share on other sites

And @Tripredacus ;), most probably we will be using Qemu 217.2 on an Ubuntu 408.25 "Wild Worry-free Wooing Wombat" with kernel 118.4.10 in order to run it on the AMINTEL i4886 1024bit processor.

I'd expect (presuming Microsoft was telling the truth) that I'd still be using Windows 8 x128 by 2038. Only because the "idea" of having a PC with an exabyte of RAM is such a mind-boggling yet fascinating idea. And to add in the fact that it would likely take me 25 years to save up enough money to buy that much RAM... Or at least a motherboard with 1 billion RAM slots on it. :w00t:

Well, let's see what could happen in 27 years applying Moore Law and/or one of the similar related ones :whistle: :

http://en.wikipedia.org/wiki/Moore's_law

http://users.hal-pc.org/~slcweb2/0MonthlyPresent/0403MooreLaw/0MooreLaw.html

BUT take into account also Wirht's Law :ph34r: :

http://en.wikipedia.org/wiki/Wirth's_law

And Jevons' Paradox:

http://en.wikipedia.org/wiki/Jevons_paradox

Basically you will need to run a small nuclear plant to get the power needed for the PC on which you will write lousy posts on MSFN or the occasional e-.mail to your grand grandsons. :angel

:lol:

jaclaz

Link to comment
Share on other sites

You probably misunderstood. :unsure:

I know that in year 2038 - if still alive - I will most probably be still using 2K (or in the worst case XP).

I was asking about you. :whistle:

No misunderstanding here. Of course I'll be using XP in 2038 and beyond. It was my question. LOL

Since XP uses 64-bit time, if I were to adjust Windows' Date and Time to the year 2040 to check that all my programs are safe or not from Y2K38, what is the worst that could happen? Could XP crash, even though it's immune from Y2K38, or would just the offending program crash, like any other protected-mode error?

Edited by vipejc
Link to comment
Share on other sites

No misunderstanding here. Of course I'll be using XP in 2038 and beyond. It was my question. LOL Is there a way to look at a program's source code with Notepad or another simple program to see if it suffers from Y2K38?

You could just change the date in your BIOS and block Windows time synchornization... :whistle:

Of course Windows Update won't work with such a configuration. :)

Link to comment
Share on other sites

Since XP uses 64-bit time, if I were to adjust Windows' Date and Time to the year 2040 to check that all my programs are safe or not from Y2K38, what is the worst that could happen? Could XP crash, even though it's immune from Y2K38, or would just the offending program crash, like any other protected-mode error?

Most probably it won't even actually crash, it will simply create/display/print/whatever "silly" dates, or, if dates are used for internal calculations, show/etc. "silly" results.

jaclaz

Link to comment
Share on other sites

Since XP uses 64-bit time, if I were to adjust Windows' Date and Time to the year 2040 to check that all my programs are safe or not from Y2K38, what is the worst that could happen? Could XP crash, even though it's immune from Y2K38, or would just the offending program crash, like any other protected-mode error?

Most probably it won't even actually crash, it will simply create/display/print/whatever "silly" dates, or, if dates are used for internal calculations, show/etc. "silly" results.

jaclaz

I'm setting up a test environment and will report the results. I'll also be contacting all software vendors I support and asking them to use an unsigned 32-bit integer for time_t in a future version, to postpone the problem until 2106, which is the best compromise, because nobody in that generation will know XP, and thus can't have an attachment to it.

Huh? I thought Windows NT was immune from Y2K38? Then what's this:

What operating systems, platforms, and applications are affected by it?

A quick check with the following Perl script may help determine if your computers will have problems (this requires Perl to be installed on your system, of course):

#!/usr/bin/perl

#

# I've seen a few versions of this algorithm

# online, I don't know who to credit. I assume

# this code to by GPL unless proven otherwise.

# Comments provided by William Porquet, February 2004.

# You may need to change the line above to

# reflect the location of your Perl binary

# (e.g. "#!/usr/local/bin/perl").

# Also change this file's name to '2038.pl'.

# Don't forget to make this file +x with "chmod".

# On Linux, you can run this from a command line like this:

# ./2038.pl

use POSIX;

# Use POSIX (Portable Operating System Interface),

# a set of standard operating system interfaces.

$ENV{'TZ'} = "GMT";

# Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.

for ($clock = 2147483641; $clock < 2147483651; $clock++)

{

print ctime($clock);

}

# Count up in seconds of Epoch time just before and after the critical event.

# Print out the corresponding date in Gregorian calendar for each result.

# Are the date and time outputs correct after the critical event second?

I have only seen a mere handful of operating systems that appear to be unaffected by the year 2038 bug so far. For example, the output of this script on Debian GNU/Linux (kernel 2.4.22):

# ./2038.pl

Tue Jan 19 03:14:01 2038

Tue Jan 19 03:14:02 2038

Tue Jan 19 03:14:03 2038

Tue Jan 19 03:14:04 2038

Tue Jan 19 03:14:05 2038

Tue Jan 19 03:14:06 2038

Tue Jan 19 03:14:07 2038

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Windows 2000 Professional with ActivePerl 5.8.3.809 fails in such a manner that it stops displaying the date after the critical second:

C:\>perl 2038.pl

Mon Jan 18 22:14:01 2038

Mon Jan 18 22:14:02 2038

Mon Jan 18 22:14:03 2038

Mon Jan 18 22:14:04 2038

Mon Jan 18 22:14:05 2038

Mon Jan 18 22:14:06 2038

Mon Jan 18 22:14:07 2038

Link to comment
Share on other sites

Huh? I thought Windows NT was immune from Y2K38? Then what's this:

Owww, come on :w00t: :

What operating systems, platforms, and applications are affected by it?

.....

use POSIX;

# Use POSIX (Portable Operating System Interface),

# a set of standard operating system interfaces.

....

....

The issue is known:

http://en.wikipedia.org/wiki/Year_2038_problem

it mainly affects Unix based OS (and conversely POSIX times)

....

jaclaz

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...