Y2K38 Watch Starts Saturday

Jon Masters writes "I just wanted to remind everyone that Saturday, January 19th 2008 will mark the beginning of the 30-year countdown to the Y2K38 bug, when Unix time will overflow 32 bits. Some 30-year loan calculation software might start having problems with this over the weekend."

Re:WTF are you talking about?

[riseoftheindividual]

A lot of loan calculation software does more than just calculate interest rates. They can also produce payment schedules and amortization over the life of the loan, up till the last payment.

Re:WTF are you talking about?

[avandesande]

Yeah, and most loan deals are put together weeks or months before closing. We would have already heard something by now.

Incorrect....

[gweihir]

Older flavours of Unix will wrap-around on 32 bit int. More modern systems use time_t instead of int and may or may not be affected by the problem. time_t can be unsigend (which gives another 68 years) or long long int/long long unsigned (which are both 64 bit long). In any case, fixing the basis library and recompileing is enough for properly implemented software.

Don't forget embedded!

[EmbeddedJanitor]

There were approx 200 million PCs sold in 2007 and 4 billion embedded systems (1:20). Most embedded systems are still using 8-bit CPUs. A 64-bit world is still a long way off.

Re:The answer is 64!

[KillerBob]

Considering that they were making 8-bit chips in 1972, 16-bit chips in 1979, 32-bit chips in 1986 ('386 was a 32-bit chip... SX was 32-bit internally on a 16-bit bus, and DX was 32-bit bus too), and by 1991 64-bit chips (the DEC Alpha leaps to mind). Even today, most graphics processors are 128-bit chips, and I believe there's even some 256-bit processors on the horizon for NVidia/ATI if they aren't already here. I suspect that by that time 2038 rolls around nobody will still be producing lowly 64-bit chips. Probably by that time even 256-bit chips will be considered antiques.

Re:Unix is made of *FAIL*

[ewilts]

> VMS has been Y10K-compliant for over a decade.

It's much better than that. It's mostly DCL that has the year 9999 issue. For those of you who like history lessons and how to design real operating systems (and customer support, back when it actually existed), read this article:

  38 Why Is Wednesday November 17, 1858 The Base Time For VAX/VMS?

COMPONENT: SYSTEM TIME OP/SYS: VMS, Version 4.n

LAST TECHNICAL REVIEW: 06-APR-1988

SOURCE: Customer Support Center/Colorado Springs

QUESTION:

Why is Wednesday, November 17, 1858 the base time for VAX/VMS?

ANSWER:

November 17, 1858 is the base of the Modified Julian Day system.

The original Julian Day (JD) is used by astronomers and expressed in days
since noon January 1, 4713 B.C. This measure of time was introduced by
Joseph Scaliger in the 16th century. It is named in honor of his father,
Julius Caesar Scaliger (note that this Julian Day is different from the
Julian calendar named for the Roman Emperor Julius Caesar!).

Why 4713 BC? Scaliger traced three time cycles and found that they were
all in the first year of their cyle in 4713 B.C. The three cycles are 15,
19, and 28 years long. By multiplying these three numbers (15 * 19 * 28
= 7980), he was able to represent any date from 4713 B.C. through 3267 A.D.
The starting year was before any historical event known to him. In fact,
the Jewish calendar marks the start of the world as 3761 B.C. Today his
numbering scheme is still used by astronomers to avoid the difficulties of
converting the months of different calendars in use during different eras.

So why 1858? The Julian Day 2,400,000 just happens to be November 17, 1858.
The Modified Julian Day uses the following formula:

      MJD = JD - 2,400,000.5

The .5 changed when the day starts. Astronomers had considered it more
convenient to have their day start at noon so that nighttime observation times
fall in the middle. But they changed to conform to the commercial day.

The Modified Julian Day was adopted by the Smithsonian Astrophysical Obser-
vatory (SAO) in 1957 for satellite tracking. SAO started tracking satellites
with an 8K (non-virtual) 36-bit IBM 704 computer in 1957, when Sputnik was
launched. The Julian day was 2,435,839 on January 1, 1957. This is
11,225,377 in octal notation, which was too big to fit into an 18-bit field
(half of its standard 36-bit word). And, with only 8K of memory, no one
wanted to waste the 14 bits left over by keeping the Julian Day in its own
36-bit word. However, they also needed to track hours and minutes, for which
18 bits gave enough accuracy. So, they decided to keep the number of days in
the left 18 bits and the hours and minutes in the right 18 bits of a word.

Eighteen bits would allow the Modified Julian Day (the SAO day) to grow as
large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this allowed for seven
centuries. Using only 17 bits, the date could possibly grow only as large as
131,071, but this still covers 3 centuries, as well as leaving the possibility
of representing negative time. The year 1858 preceded the oldest star catalog
in use at SAO, which also avoided having to use negative time in any of the
satellite tracking calculations.

This base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20, and
VAX/VMS. Given this base date, the 100 nanosecond granularity implemented
within VAX/VMS, and the 63-bit absolute time representation (the sign bit must
be clear), VMS should have no trouble with time until:

      31-JUL-31086 02:48:05.47

At this time, all clocks and time-keeping operations within VMS will suddenly
stop, as system time values go negative.

Note that all time display and manipulation routines within VMS allow for
only 4 digits within the 'YEAR' field. We expect this to be corrected in
a future release of VAX/VMS sometime prior to 31-DEC-9999.

Re:2048

[Curien]

Not "real binary"? WTF are you talking about? It's either binary or it's not. And it's binary.

As for your poorly-made argument that computers use words with certain widths, just because you've never used a computer where CHAR_BIT != 8 doesn't mean they don't exist.

Here we go again, year2038.pl

[quarkie68]

#!/usr/bin/perl
# (or wherever your camel lives)
#Copyleft (just joking!) Georgie http://folk.uio.no/georgios
use POSIX;
use strict;

$ENV{'TZ'} = "GMT";
# GMT for preference
print "And the transition will be like...\n";
for (my $clock = 2147483646; $clock < 2147483650; $clock++)
{
    print ctime($clock);
}

chomp(my $conclusion=ctime(2147483650));
if ( $conclusion=~ /1901$/) {
        print "Which means that you are bugged by 32 bits. We have 64 bit processors and structures now you know!\n";} else {
        print "You will survive for now. Go and get a beer. \n";}

Re:64, 128, 256...

[Sam Douglas]

You *can* work with data type sizes larger than your CPU's word size in software. For example, if you need to add/subtract 128 bit integers, it is not terribly difficult to do -- it just takes multiple instructions and using the carry-out/overflow bit on you adder. Don't think that a hardware 'improvement' will magically fix software. It is just convenient to use 32 bit numbers as they can be operated on in a single instruction on most modern architectures. Also, increasing the width of your CPU datapath is not something that can be pushed up forever. A simple 256 bit adder would require at least 768 inputs/outputs. At some point it becomes a lot more efficient to change your approach!

Re:The answer is 64!

[frieko]

I'd like to point out that thanks to the carry bit, an 8-bit CPU can do 64-bit math. In fact, any Turing-complete device can do 64-bit math. This is strictly a software issue.

Re:Of course they did.

[KillerBob]

I can remember coming across a book about the entire Y2K thing back in the late '70s, filled with both dire warnings and algorithms. And I remember thinking, "Jeez, that's over 20 years away. Nobody's going to be using any software around today that far in the future."

My dad was actually hired by the Bank of Canada in the early 1970's to update their software to be Y2K compliant....

So yes... they were well aware of it back then. Likewise, they've been aware of the 32-bit Unix time expiry since they introduced Unix time. I'd be surprised if they weren't already working on a solution. Actually... I'd be surprised if they hadn't already implemented a solution to it.

Pure alarmism. Just like we had in 1999.

Re:And other things..

[hansamurai]

Lack of coverage and donations? I would agree that at least coverage wise, the tsunami did not grab the nation the same way 9/11 did, but looking at the money donated is another story.

First I would encourage you to look at this:
http://en.wikipedia.org/wiki/Humanitarian_response_to_the_2004_Indian_Ocean_earthquake#List_of_Donors [wikipedia.org]

The United States government donated nearly one billion dollars and another 1.9 billion came from its citizens and NGOs. That's nearly 3 billion dollars total. A total of 10 billion dollars was given to relief from around the world.

Granted, that comes to around 0.0026% of our GDP (someone correct me if I'm reading that wrong, permilles aren't my strong suit), but it's still a massive out pouring of money if you ask me.

Signed 12-bit

[tepples]

No I'm pretty sure 11 bit computers are exceedingly rare and there wont be any problems because of them. :)

Some PDP minicomputers by Digital [wikipedia.org] were 12-bit. A 12-bit signed integer data type can represent whole numbers from -2048 to 2047.

Re:2048

[TheThiefMaster]

It's "Number of seconds since midnight (0:00:00) January 1st 1970". Which in a SIGNED 32-bit number, overflows into negative in 2038.

If they'd used an unsigned 32-bit number, then they would have had dates up to 2106 covered. Unfortunately whoever invented these timestamps chose to make them use signed numbers, with negative numbers being allowed on some systems (representing dates before 1970) and being errors on other systems (e.g. Windows)...

Fortunately 64-bit numbers can now be handled by pcs, and can be used as an extended timestamp to get a few billion years of time. Most operating systems have already been converted, it's just legacy programs that would have issues.

Even more significant dates

[spydink]

2038 is just the tip of the iceberg!!!

Significant dates [demon.co.uk]

Re:2038

[dhanson865]

Nobody stores years as 11 bit integers. Would you care to share the goofy math that made you pick 11bit instead of 32bit?

The year 2038 problem (also known as "Unix Millennium bug", "Y2K38," "Y2K+38," or "Y2.038K" by analogy to the Y2K problem) may cause some computer software to fail before or in the year 2038. The problem affects Unix-like operating systems, which represents system time as the number of seconds (ignoring leap seconds) since January 1, 1970. This representation also affects software written for most other operating systems because of the broad deployment of C. On most 32-bit systems, the time_t data type used to store this second count is a signed 32-bit integer. The latest time that can be represented in this format, following the POSIX standard, is 03:14:07 UTC on Tuesday, January 19, 2038. Times beyond this moment will "wrap around" and be represented internally as a negative number, and cause programs to fail, since they will see these times not as being in 2038 but rather in 1970. Erroneous calculations and decisions may therefore result.

Re:And other things..

[Surt]

Some links for the interested:

http://en.wikipedia.org/wiki/Humanitarian_response_to_the_2004_Indian_Ocean_earthquake [wikipedia.org]

http://en.wikipedia.org/wiki/Financial_assistance_following_the_September_11%2C_2001_attacks [wikipedia.org]

The bottom line seems to be that the government response to 9/11 was substantially larger (to compensate the victim's families, who were very high earners, and which was essentially necessary to rescue the airline insurance industry from lawsuits). Whereas the public outpouring of donations to victims was quite a bit larger for the tsunami.

Re:64, 128, 256...

[lgw]

Windows uses 64-bit file times everywhere now, and has for years. Probably in reaction to the 49-day uptime limit on Win9x (where the 32-bit "ticks" counter - ms of uptime - would roll over).

Very expensive NAS boxes still use 32-bit file time. It's odd, really.

Re:What about the new 40 and 50 year loans?

[jandrese]

That and most of the Y2K problems were just display errors, not bugs in the actual calculations going on under the scenes. 2038 is much scarier and is a lot more difficult to fix. In fact the best way to fix the problem is probably to switch to a 64 bit representation of time, but thus far not too many people have made moves in that direction. Switching to 64 bits is not as easy as it might sound either, since lots of programs use timestamps and many of them make assumptions as to the size of their time fields. I do wish APIs would start to get transition structures (time_t64 or something) in place that people could start using now. If you do it early enough you can save yourself a lot of headaches down the road.

The big problem of course is that most people figure their code won't be in use in 2038 and don't care. I'll be right about retirement age by then. Crap, I just realized I'm going to be the grizzled old guy they call when this problem finally rolls around. One of those crusty old farts that knows C (just like the crusty COBOL farts that got a lot of jobs back in 1999 for a few months).

Re:And other things..

[DetJohnKimball]

You are right that a National ID card in the UK was not considered. However, what was considered was an Irish ID Card. It was desired that all Irish in the UK had to show ID and sign a photo every time they wanted to rent an apartment, buy a house, or get a hotel room.

The seller/owner would have been required to keep this information in case the Irish person bombed some place and they could begin to track them.

Of course the politician that proposed this instantly rose to the top of the IRA assassination list. I can't remember if it was PM Edward Heath or not. Edward Heath did introduce internment in Northern Ireland where Catholics could be detained and sentenced without a trial. That did lead to a failed assassination attempt by the Balcombe Street Gang.

Re:And other things..

[DigitalCrackPipe]

lack of coverage and donations given to the victims of the tsunami
Not sure what numbers you're reading. According to this [wikipedia.org] article on the Tsunami,

In all, the worldwide community donated more than $7 billion (2004 U.S. dollars) in humanitarian aid.

It's not very productive to directly compare an event with such political magnitude to a natural disaster, without taking other factors into consideration. Try comparing Hurricane Katrina to the tsunami, and then adjust for scale, for a better idea of how limited the reach of media and donations are.

Re:The answer is 64!

[zienth]

thegrassyknowl said:
I guess it's a fault of the Unix people from way back. They made this epoch thing and used a 32-bit number to store the number of seconds since it. I guess they were assuming that all their software would have been replaced by something better on bigger machines. They shouldn't have written such reliable software and then maybe some of it would have been replaced by now ;)

Well, the Unix people from way back were writing for a PDP-11, which was a 16 bit machine. I'd guess their early compilers didn't have an int type with more than 32 bits. Actually, since the Unix kernel was originally written in assembly, they may have used a 32-bit int because anything bigger was just a pain to write code with. I'm not sure whether a 32-bit time_t was in use before they re-wrote the kernel in C in 1973 or not. Keith

Re:The answer is 64!

[Rodyland]

software that's recompiled for 64-bit machines will automagically use 64-bit ints where the programmer held the time in an int.

Umm... no.

Depending on your architecture (x86, sparc for two) and compiler (sunpro for one), 64bit compilers may still define an int as 32 bits, but redefine long, time_t, size_t, ptrdiff_t etc. as 64-bits (and FYI long long is also still 64bits).

So, if an programmer has typed

int i = time(NULL);

then that code is still going to have the Y2K38 bug in it when recompiled in a 64 bit environment.

Re:Not a significant date

[Mesa MIke]

30 years is the standard length of a mortgage loan.

Re:I can't wait!

[Anonymous Conrad]

If we are sill running 32 bit software in 2038 I will fully blame MSFT.

But 32-bit OS can still use 64-bit numbers. And they do! In fact Windows's native time format [microsoft.com] *is* 64-bit.

Re:2048

[stonecypher]

Unfortunately whoever invented these timestamps chose to make them use signed numbers, with negative numbers being allowed on some systems (representing dates before 1970) and being errors on other systems (e.g. Windows)...

Whoever invented these timestamps did so before Microsoft was formed. According to The History of Computing Project, the earliest known reference to Microsoft is an announcement of the partnership as Micro-Soft [thocp.net] in a Nov 29 1975 personal letter. The UNIX time date stamping system was in use in V1 in 1971 (though not in UNICS). I have it on suspicious authority that the mechanism may be inherited from a Multics mechanism with a different epoch date, but I cannot find proof.

It's got less than nothing to do with Windows, and it's not about system compatibility. The choice of a signed number was simple: at the time, timespans were encoded as negative numbers. That was removed by v2 because it caused a lot of problems in naively written code. You're presenting guesswork as fact: that's a particularly pernicious form of lying, because other people start to repeat it, thinking it's true. Quit being such a kneejerk jerk. You have no idea what you're talking about.

Fortunately 64-bit numbers can now be handled by pcs

Mechanisms for handling 64 bit numbers have been in every edition of UNIX sold or distributed for more than 20 years, since the POSIX consortium was called in 1985 to standardize the existing differing mechanisms between Ultrix, SunOS, MIPS/BSD/Mach, V8, Xenix and so on. Stop making things up to seem smart.

Whoever marked that informative should contact me for bill of sale in re: Brooklyn Bridge.

Re:And other things..

[Somegeek]

Quote Tango42:

The IRA's bombings weren't (in most cases) intended to kill people, they even gave warnings so the appropriate areas could be evacuated. I guess they just wanted publicity for their cause for the most part.

What IRA are you talking about? The Provos, which is what most people refer to as the 'IRA', were responsible for somewhere around 1,800 deaths during "The Troubles", from the late '60s through the late '90s. During this same period they were responsible for approximately 20,000 wounded.
http://en.wikipedia.org/wiki/Provisional_Irish_Republican_Army#Casualties [wikipedia.org]

Their primary strategy was "A war of attrition against enemy personnel [British Army] based on causing as many deaths as possible so as to create a demand from their [the British] people at home for their withdrawal."
http://en.wikipedia.org/wiki/Provisional_Irish_Republican_Army#The_.22Long_War.22 [wikipedia.org]

'as many deaths as possible'.