Billennium's Over - Anything Break?

An Anonymous Coward writes: "The billennium party at OpenProjects.Net rocked! Check out the log for the whole event over here. Please don't forget to use one of the mirrors. Thanks :-)" Well, anyone have anything break due to the rollover?

Comments

really small stuff

[KFury]

I use a thingy that portions my web logfiles into daily files, each prepended with the current unix timestamp. I found that scripts I run to do stuff with the most recent day's logfile broke because 1000000000access_log.gz comes before 999999999access_log.gz.

The simple solution is to move the old 999 files to another directory. This problem wouldn't have cropped up since 1973 when it passed eight 9s, and won't happen again for another 300 years when it passes ten 9s.

Still, a bug's a bug, and that's one more than I had in the new millenium.

Re:really small stuff

[Cef]

You could just prepend a 0 to the front of the old filenames, and it'll sort them all correctly.

See what happens when you don't use leading zeros? *grin*

Re:really small stuff

[Bronster]

You could just prepend a 0 to the front of the old filenames, and it'll sort them all correctly.

See what happens when you don't use leading zeros? *grin*

So you'd recommend using 000000000000000000000000000000000000access_log.txt
just in case then?

Seriously though, in this case there's a known maximum size of that value, and one more 0 would have been enough (at least until we go 64bit time_t)

Jumping down to shorter values though (say 3 digit long), do you write:

23 387 96 1 12 32 43

or

023 387 096 001 012 032 043

or even
00000023 00000387 00000096 00000001 00000012 00000032 00000043

I vote for realising that you have a numeric value and splitting the int off the start and sorting by that. Bit hard in shell scripts though.

Re:really small stuff

[G-funk]

You could just prepend a 0 to the front of the old filenames, and it'll sort them all correctly.

It's attitudes like that that get us all into trouble mister! That sort of talking till get us all into trouble! You should know that 13 and 013 are different numbers, one being 13, and the other being 11 :-) Of course 011 is 9 but I digress :-)

Re:really small stuff

[Zero__Kelvin]

"You could just prepend a 0 to the front of the old filenames, and it'll sort them all correctly."

"See what happens when you don't use leading zeros?*grin*"

Workarounds are for when you can't do it right. In this case the solution is way too simple to merit a workaround. Simply do math on scalar types, not strings. If your language doesn't know the difference never use it for anything again. If you don't know the difference, learn. Simple, see?

Re:really small stuff

[zdzichu]

>The simple solution is to move the old 999 files >to another directory. This problem wouldn't have >cropped up since 1973 when it passed eight 9s,
>and won't happen again for another 300 years when
>it passes ten 9s.

Do I remember correctly that another 300 years won't happen, because in 2038 timer will roll-over?
If we not got 64-bit timestamp, of course.

Re:really small stuff

[Nailer]

Alternatively, you could fix directory sorting so that it accurately reflects the way most people save their files.

Oh yeah...

[SamMichaels]

I stored the date as a 9 character string in the MySQL table. Oops.

I increased it to 10 chars but now it doesn't sort it correctly. Ooops.

I had the expire date on the cookies set to "999999999". Ooops.

I'm sure loads more will pop up.

The Y2k+1 "bug" really got me.

Re:Oh yeah...

[JabberWokky]

MySQL doesn't have a ANSI Date field? Why am not surprised...

It very much does, which brings up the point that the reason many MySQL databases suck is not due to the engine itself, but rather due to the newbies who create them.

--
Evan

Re:Oh yeah...

[stripes]

It very much does, which brings up the point that the reason many MySQL databases suck is not due to the engine itself, but rather due to the newbies who create them

That is true of a great many databases...however there are some good reasons to store time as a time_t in a (wide enough) int field. Many (not all!) DB dates don't handle times. Some have bugs (XDB's day of week was off by a day in 2000 for example -- they patched that in October '99). Many have timezone problems, or problems with switching from "standard" to "daylight".

Sure for the most part storing things as time_t's just papers over this sort of thing, as the problems can crop up if you don't manipulate them correctly (and not all libc's do!), but I do think it is a little simpler to fix your own code then the DB itself (...except for MySQL, and Postgress, where you at least have the chance to fix the date handling code in the DB...and where I would assume they don't think they are smarter then libc and break things like many commercial venders...)

Don't be a moron and store numeric data like time_t's in char fields though :-)

older Kmail (from KDE 1.x) billenium bug

[romanm]

Apparently there is a bug in older version of KMail from KDE 1.x that prevents KMail from correctly displaying the current date since billenium. More information about KMail billenium bug is on www.kde.org.

broken CVSup on FreeBSD

[mbadolato]

Well, anyone have anything break due to the rollover?

This was sent out to the freebsd mailing lists by John Polstra:

This morning a bug was discovered in most versions of CVSup up to and including SNAP_16_1c. The bug causes all newly-updated files to receive incorrect timestamps. Usually the files receive timestamps from early in 1970. This bug has been present for a very long time,
but it only began to have an effect when the Unix representation of the date and time passed 1,000,000,000. That occurred on 9 September
2001 at 01:46:40 UTC. Yes, other people had Y2K bugs, but I managed to produce an S1G bug.

There was more, but that was the jist.

Re:broken CVSup on FreeBSD

[dsfox]

This bug may have caused the dates on some of the files in the XFree86 source tree to be reset to Jan 1, 1970. Or maybe not.

Anything Break?

[rchatterjee]

From my understanding the major problem doesn't occur till 2038 when 32-bit time reaches 2,147,483,647 seconds. 2,147,483,647 is the biggest number a 32-bit system can register.

Re:Anything Break?

[rchatterjee]

We hope but remember what happened for Y2K, a mad dash to rewrite 20 - 30 year old COBOL and other progs that listed the date in only 2 digits and the original programmers thought would be replaced years before Y2K came up.

Re:Anything Break?

[xcomputer_man]

Hmm..true, but in the past 20 years we have progressed from approximately 4 bits to 32 bits. It would be ridiculous to think that 37 years from now, 32-bit computers would not be living in museums. I think the greatest concern would be die-hard win95 addicts, who would have to be content with the final blue screen of death when this happens.

Re:Anything Break?

[Kris_J]

Hey, I bought a Sega Mega CD II *new* from a local department store just under a month ago. I also bought a Mega Drive II to match. I believe they each have a 68000 in them, and that's 16 bit (at least externally). Old CPUs fade away much slower than you think.

Re:Anything Break?

[IvyMike]

Nope, there are some more dates with problems prior to 2038, see this list for some of the more important ones. (I saw a more extensive list once during the pre-Y2K buildup, but those web sites have mostly disappeared. Anyone?)

Re:Anything Break?

[Bj�rn Stenberg]

2,147,483,647 is the biggest number a 32-bit system can register.

Umm, no. That'd be a 31-bit number, as is the case with time_t which is a SIGNED integer. A 32-bit value can hold 2^32-1 = 4,294,967,295.

Can anyone tell me why this is a Real Problem? The obvious solution is to simply change the compilers from:

typedef long time_t;

to:

typedef unsigned long time_t;

And we can merrily keep using time_t on our 32-bit systems until 2106.

Yeah, fubar systems will break. And yeah, we'll have to change some kernel API parameter types. Cry me a river!

Re:Anything Break?

[Dr. Evil]

And what about embedded systems? Many of them still use 8 bit microprocessors.

Re:Anything Break?

[Anonymous Coward]

Actually, 4-bit computers are still commonly used in small things - like microwaves, VCRs, remotes. Lucikly, I haven't seen the infamous "end-of-the-week bug" occuring at the day 7 rollover.

Re:Anything Break?

[pne]

(I saw a more extensive list once during the pre-Y2K buildup, but those web sites have mostly disappeared. Anyone?)

There's a really extensive one at http://www.merlyn.demon.co.uk/critdate.htm, by J R Stockton.

Re:Anything Break?

[RuneB]

As a guess, probably because of the way the time() function works.

You can pass a pointer to time(), and it will store the current time in the specified memory location, in addition to returning the value.

What happens when you pass an invalid pointer to the function? errno is supposed to be EFAULT, and thus time() can return -1.

In Linux, system calls directly return the errno as a negative number, and the kernel and libc reserve the first 4095 negative numbers for this purpose. Since time_t is signed, this isn't a problem. However, you would have a problem if you could not distinguish an errno return from a valid return value.

Now, forcing everyone to use gettimeofday() instead of time() would help solve this problem.

Re:Anything Break?

[Dr. Evil]

But some of them do...

Re:Anything Break?

[SecretAsianMan]

There's still a problem with using 4 digits. When the year becomes 10000 you'll need 5 digits. Oh wait, I think I'm beginning to feel enlightened...

The previous text was a special presentation by a sarcastic asshole.

A possible connection?

[acb]

Hmmm... the Melbourne General Post Office was gutted by fire at around the same time as the Billennium. Do you suppose...?

An entire HD

[bee-yotch]

Now that you mention it one of my hard drives completely stopped working. At first I thought it was because i had it sitting on my floor and I stepped on it. I didn't even realize that it was probably from the whole 1 billion thing. Man, what was I thinking?

knode

[anshil]

knode (0.4)

The kde news reader now orders incoming messages false. All new messages after the billenium are ordered older than the ones from before.

Re:knode

[anshil]

it just because of the great advantage of kde, a 'k'ommon environment :) That means kommon libraries where they make sense, this saves quite an amount of memory nicely on a running system, and be surprised or not kmail and knode use the same library for the same task, with the same bug.

-1 troll

CVSup got bit by the 1 billion seconds epoch bug

[krausedw]

Updates to Fix the CVSup 1000000000 Second Bug
http://people.freebsd.org/~jdp/s1g/

Databases item types and sin

[xixax]

Just about every item in the MySQL RDBMS I inherited uses varchar(100). I toyed with converting them, but too much of the code written around it assumes that its getting text.

The best solution is to make sure anyone who creates a database has to administer it.

Xix.
(off to check some circa 1983 database technology to see if it's croaked in the interval)

BTW,

[popeyethesailor]

Thanks for the Log. The commentary was brilliant.

My mail client - pronto broke.

[crazney]

It uses strings of unix time to sort the messages in the message list by date. So after the billenium all new messages where going to the bottom..

Anyway, i've made a small fix, incase anyone wants it..
Put it in MessageList.pm line 530.

# fix for billenium, we want to be able to make sure all string that get sorted are the same length so no boo boo's happen
if (length($row[5]) == 9)
{
my $tmp = $row[5];
$row[5] = "0$tmp";
}

Re:My mail client - pronto broke.

[AdamT]

The only time this matters is in comparisons and sorting. Perl has explicit numeric and string tests for both of these activities.

$a &lt=&gt $b :- sort numericaly
$a cmp $b :- sort as strings

$i lt $j :- compare as strings
$i &lt $j :- compare numericaly

... if someone uses the wrong test they've no one but themselves to blame.

Re:My mail client - pronto broke.

[Chagrin]

The fact that Perl has vague distinctions between strings and numbers has very little to do with the situation at hand. The problem with the billennium bug is that there's a risk that programmers did not allocate enough digits to hold a date correctly; since both Perl and Python reallocate memory to handle larger values internally, your Python will succeed or fail in an equal number of situations as Perl. It's not an issue of the actual program language, the issue is how the date is persistently stored when the program ends (a database, columnar text file, or whatever).

You're not flamebait because you're a Python bigot, you're flamebait because your post is an invalid rant and off-topic.

Re:My mail client - pronto broke.

[NitsujTPU]

Neither is a product that I want my mail reader written in. If I'm going to have something that I want fast, that is running in my native gui, that does not need to be portable and is not running a scripting task, I would prefer for it to be in compiled machine code. Even emacs lets you compile as much of it's scripting as it can.

Re:My mail client - pronto broke.

[muhri2]

I just wanted to clarify things a bit here as the reason Pronto broke was not Perl related. It was because Gtk+ (Which I depend on it for sorting) used alpha numeric sorts. I just replaced the default Gtk+ sort routines with my own PERL sort routine and its fixed.

PS, What can I do to get my nickname muhri back? I changed my email since the last time I logged onto slashdot and now I can't seem to get it to mail me my password, I feel like a hotmail user hehe, muhri2!!

Re:My mail client - pronto broke.

[ajs]

I'm missing something. Why would the fact that length(time()) just jumped from 9 to 10 matter? I take it as a matter of faith that anyone who can write Perl code that would care can write Python, C++, Java or Pascal that will fail in all sorts of interesting ways as well.

You can code "shoot self in foot" in any language. Python just makes you use a particular caliber gun which Guido feels is the only right way that one should shoot one's own foot.

Larry, on the other hand feels that assembly is too restrictive in its foot-shooting options.

To each his own.

Re:My mail client - pronto broke.

[GreyPoopon]

The problem with the billennium bug is that there's a risk that programmers did not allocate enough digits

Actually, I think most of the posts I've read so far indicate not a problem in storage allocation, but instead a problem in sorting -- IE, they used a string sort rather than numeric.

your Python will succeed or fail in an equal number of situations as Perl

Sorry, I disagree. I'm neither a Python nor Perl biggot (don't have much time to devote to either), but the point made in the parent post was that in a strongly typed language like Python, programmers are prevented from using the wrong form of comparison. Yes, Perl has different comparison methods for numeric and string and yes, the programmer has nobody to blame but themselves if they make such a mistake, but having the language do a bit of idiot-proofing will ultimately yield fewer bugs. So no, I don't think there will be an equal number of failures in Python.

Note that I don't think this makes Python "better" or Perl "worse." It's just a feature that needs to be considered when choosing a language for a project.

Re:My mail client - pronto broke.

[stripes]

Python, programmers are prevented from using the wrong form of comparison

Sure, except we have already seen in another strongly typed language (SQL) where programmers chose to store time_t's in char (or varchar) variables, so the built in sorting can screw them.

Now I think Python programmers are frequently smarter then SQL programmers :-) they can still make the same mistake. (I actually do think they are on the whole a little smarter, but only because many SQL users are forced to use it, and don't want to, while most Python programmers chose to use Python...)

So you see strongly typed languages don't remove all type errors...

Re:My mail client - pronto broke.

[smallpaul]

I can't believe this guy was modded up to 4. You moderators are really showing off your lack of understanding of the issue. Here's the original problem report:

It uses strings of unix time to sort the messages in the message list by date.

Python sorts time_t's as integers, not strings. Perl sorts integers and strings the same unless you tell it otherwise. I saw my first report of this kind of Perl sorting bug within a few hours of the billenium. When I saw a second one on slashdot my "crappy software sucks" meter went past the "trashing other languages isn't politically correct" threshold. Perl is full of these little insecurities.

People have a naive faith that there is no real cost to Perl's short-cuts but here is some more anecdotal evidence as if we needed any..

Re:My mail client - pronto broke.

[smallpaul]

As I said in another post, if your language doesn't know the difference between scalar types (which perl *does*) then never use it again.

Perl can be told that you mean to deal with strings as integers but it is stretching to say that Perl really knows the difference between strings and integers. It allows you to "add" "a"+"b" (and get 0 -- totally logical!) and it allows you to "concat" 7 and 53. Maybe Perl knows the difference but it doesn't tell you in time to help you find subtle type bugs....

Re:My mail client - pronto broke.

[Chagrin]

See http://slashdot.org/comments.pl?sid=21493&cid=2272 567. The problem is in GTK+'s sorting algorithm (alphanumeric) and has nothing to do with the interfacing language.

So, if pronto had been written in Python, what would be the likelihood of the same bug popping up? It would be equal, thus your post has little relevance to the problem at hand. Any language would fall prey to this problem if its programmer overlooked the fact that the widget's interface sorts alphanumerically, even your wonderful "strongly-typed-makes-me-a-better-programmer" languages.

Re:My mail client - pronto broke.

[fanatic]

But the issue is still not allocating enough digits lexically, eg using:

$filename = time() . $filename;


instead of:

$filename = sprint("%012d", time()) . $filename;

which gives extra zeroes up front. (is 12 enough digits for the LONG term?)

Canon S10

[AftanGustur]

I haven't had time to fully investigate the cause but the software that came with my Canon S10 digital camera now claims that I took all my pictures on August the 26th (at different times though that day).

The software (is supposed) to read the time from a field in the images .jpg comment field.

The cause could be 1) The software in the camera that stores the dates in the images or 2) the photo viewing software itself. or 3) Something totally different. (Windows ?)

OpenLDAP slave servers completely broken

[che]

I submitted this as a story, but I guess it never got accepted. Ah well..

OpenLDAP has massive breakage both in the 1.2 and 2.x series with the S2G Unix time rollover.

The slurpd server completely fails to push updates from the master server to the slaves, due to string compares of timestamps in 1.2 and a related problem in 2.x. There are patches for both in OpenLDAP CVS.

The problem is detailed in the openldap-bugs mailing list -- it was extremely scary to come to work this morning and find out that all the LDAP servers had stopped pushing updates, causing account creations to fail and mail to bounce!

As a matter of fact...

[jgerman]

...yes, I was monitoring my servers at work from my home Linux box, after verifying that everything was fine I turned around ... and my Windows box had crashed, it was the damndest thing < grin > .

Well, it *nearly* broke...

[Llanfairpwllgwyngyll]

Had a party to celebrate, got drunk and very nearly broke my skull open on the floor as I fell.

Does that count? *grin*

Anything Break? DID YOU NOT NOTICE?

[Lord Bitman]

It's the GOD DAMN APOCOLYPSE Outside! Dont any of you guys ever even open a Window!? sheesh... after all those rants about how the military should switch to linux, the world ended yesterday.
Well anyway, I declare myself God until further notice.

Re:Anything Break? DID YOU NOT NOTICE?

[PrometheuSx11]

while its true, that i have not infact looked outside today, I'm ninty nine percent sure he's lying folks.

I mean, i can still connect to slashdot...

so that's got to mean he's lying right?
though i dont want to piss of this god too, cause that really came and bit me on the erse last time...

damnit, this better not be some kinda joke, cause I'm gonna have to go outside now.

.. now where the heck was that door again?

Re:Anything Break? DID YOU NOT NOTICE?

[dimator]

I hereby pledge my allegiance to Lord Bitman, our God.

[bows head]

cvsup broke

[OpperNerd]

This morning a bug was discovered in most versions of CVSup up to
and including SNAP_16_1c. The bug causes all newly-updated files to
receive incorrect timestamps. Usually the files receive timestamps
from early in 1970. This bug has been present for a very long time,
but it only began to have an effect when the Unix representation of
the date and time passed 1,000,000,000. That occurred on 9 September
2001 at 01:46:40 UTC. Yes, other people had Y2K bugs, but I managed
to produce an S1G bug.

I have fixed the bug and have released a new snapshot of CVSup,
SNAP_16_1d. I have also created binary packages for FreeBSD-4.x which
can be installed using "pkg_add". For information about updating your
CVSup installation, look here:

http://people.freebsd.org/~jdp/s1g/

To fix the bug, both the client and the server need to be upgraded to
SNAP_16_1d. The FreeBSD mirror site maintainers have been working
feverishly to upgrade their installations. Many of them are already
upgraded, and the rest will be upgraded soon. Meanwhile, all CVSup
users should upgrade their CVSup installations.

I apologize for the inconvenience caused by this bug, and thank you
in advance for your patience.

John Polstra

Maildir-based IMAP server broke

[Dave Dribin]

My ISPs IMAP server broke. It used the maildir format and got *really* confused with file names like:

% ls -tr | tail
999878615.18243.pop.xxx.com:2,S*
999882709.76833.pop.xxx.com:2,RS*
999883989.13343.pop.xxx.com:2,S*
999900385.97510.pop.xxx.com:2,S*
999906796.21947.pop.xxx.com:2,S*
999914926.66179.pop.xxx.com:2,S*
999922220.49590.pop.xxx.com:2,S*
999975475.10798.pop.xxx.com:2,S*
1000040737.72591.pop.xxx.com:2,S*
1000062814.85554.pop.xxx.com:2,*

I think it was an old version of uw-imapd with maildir patches.

I wrote a short script to rename all files created before 1,000,000,000 with a leading zero. The resulting file names with "09*" fixed the problem!

-Dave

Notice about seconds overroll

[Anonymous Coward]

I would like to make your attention on bug which was introduced tonight and can affect some people who are using (var)char field to store timestamp data.

It is not worst security bug. It affects only people who already had bug in their code. Just now this bug become visible/exploitable.

This is not MySQL bug. This is how people use their database. Also similar situation can be found in other software. I would like to inform people in public list as maybe some people have to search similar problems.

The problem: Computers store time and date usually as integer value representing amount of seconds from 1 January 1970. Tonight it overrolled from 999999999 to 1000000000.

Possible bug and exploit relies on fact that some people have used character type of field to store this seconds information (we have already such case)

example:

mysql> create table session (expire varchar(100) not null);
Query OK, 0 rows affected (0.31 sec)

mysql> insert into session values (999999997), (999999998), (999999999),
(1000000000), (1000000001);
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0

mysql>
mysql> select * from session;
+------------+
| expire |
+------------+
| 999999997 |
| 999999998 |
| 999999999 |
| 1000000000 |
| 1000000001 |
+------------+
5 rows in set (0.00 sec)

mysql>

Let's assume that this table contains values we use somewhere to authenticate users. After user logs in, we write down session expiry time and later we check it like this:

mysql> select count(*) from session where expire >= '1000032535';
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)

mysql>

WOW, what happened? Shouldn't be 100003253 bigger than any value in table? It worked yesterday!

In MySQL we suggested people to use quotation marks around integer values. This can avoid many web-based attacks targeted to modify SQL commands (more information on http://www.mysql.com/doc/G/e/General_security.html ). This is the reason why people put quotation marks around integer expressions and this is correct. Also automatic type casting will fix the source problem is column data is integer or some time/date vale. But when both column is character type and expression, they get compared as strings. And as we know, strings get sorted in order:

1,11,2,22

but integers:

1.2.11.22

So, this is why 100003253

It is possible that some web applicatons have endless expiry times now and not only in MySQL contexts.

Tonight I'm gonna party...

[Salsaman]

...like it's time_t 1E9 !!

(Shamelesly ripped from ntk.net).

Re:I thought I missed a party there...

[ayjay29]

geeks just don't DO "regular parties!"
They do over here in Sweden!
Our staff dos are a legend, and other tech companis here do the same. I have been to a lot of great parties, free food + drink, DJs, live music. Some of us even talk to girls. It must be part of the Swedish culture that once in a while you turn off your PC, grab a cold one from the fridge, hang out with your buddies and chat about things other than your OS.

Nothing Broke -- Damn

[LittleGuy]

I was expecting to have everything reset back to 1970. I was looking forward to men again on the moon and the Boston Bruins having a championship-caliber team.

Then again, I could do without the Vietnam War Redux. Oh well.

In Summary...

[SydBarrett]

Using string comparisons for dates stored as seconds since the epoch is not a very good idea.

Use the Date format that your database has, as it should be able to do much better comparisons with dates in SQL, instead of seconds stored as text.

Did I miss anything?

Veritas Netbackup

[TBone]

Veritas issued an alert that the indexing on it's backup files was broken - don't remember what it said, but basically everything would show as Jan 1, 1970 00:00:00. The datestamps were right, but the conversion routine for displaying the dates was broken. A patch that fixed the display routine fixed things up.

pine / UW IMAP

[tmu]

We use an older version of UW IMAP ad UW Pine both patched to use Maildir support (because they are too short-sighted to integrate such support themselves).

After the roll-over both programs started mis-sorting newly arrived messages to the top of the folder, rather than the bottom (but newly arrived messages are still sorted below older, within each category of 'before' and 'after' the 1 billion second point). Also getting 'mailbox changed unexpectedly, reloading' messages constantly.

Re:pine / UW IMAP

[tmu]

Excellent! I did something similar:

#!/usr/bin/perl
#
# pinefix
# Fixing the maildir pine driver bug that occurred when the 1000000000
# second roll-over happened.

use File::Find;
$maildir = shift(@ARGV);

if (!(-d $maildir)){
die "$maildir must be a Maildir";
}

print "Working on $maildir\n";

find(\&pinefix, $maildir);

sub pinefix(){
$fullpath = $File::Find::name;
$dir = $File::Find::dir;
$filename = $_;
if ( $filename =~ /^9.*/ ){
$newpath = $dir . "/0" . $filename;
link $fullpath, $newpath;
unlink $fullpath;
print "In pinefix renamed $fullpath to $newpath\n";
} else {
print "$filename does not need renaming\n";
}

}

Bah, I can't figure the new slashdot out

[tzanger]

I thought that I could go to your user info page and leave you a message since you didn't have an email addy supplied... silly me.

I was going to ask you some more questions regarding OpenLDAP and how you're using it (I'm trying to do the same types of things you described) but alas and alack, I must ask through the general messageboard. :-(

NUTS breaks

[tarsi210]

For all you talker fans out there, Neil Robertson's NUTS code (or derivitives - MoeNUTS, AmNUTS, etc.) has a constant named "DNL" that keeps track of the length of the date in seconds. This is set to 11 and will need to be switched to 12, although my talker ran fine w/o changing it. I'm sure I would have seen something wrong down the road.

A bit easier-to-understand explination.

[NNKK]

Incase someone wants this in a bit plainer english, let me explain. (Thank you, Jesse Liberty)

In C, C++, and probably most other programming languages (I'm not a guru on programming), an integer is either "signed" or "unsigned". They are also either "long" or "short". The reason for the distinctions is primarily memory-related, using a long int (4 bytes) is a waste of memory if you're just going to store say, a number up to 300 in it, in which case a short int would be more appropriate. And if you're only going to store a single byte (such as 1 or 0) there's usualy something like the int type "bool", a 1-byte long int, that allows a 1-byte value to be stored (technicaly this value could be 0 to 9, I'm not sure if negatives are allowed).

An unsigned integer is (rather obviously if you think about it) a positive-only number, you can't have a negative number in an unsigned int (well, you can try, but it'll just wrap around to its maximum value).
an unsigned long int can go from 0 to 4,294,967,295

Now, with time_t, the time is being stored in a signed long int. This can be any value from -2,147,438,648 to 2,147,483,647 (you've just split the area avalible for values between negative and positive) on a 32bit system. Unfortunitely, in 2038, that's no longer enough (DOH!) as the # of seconds from UNIX Epoch will pass the maximum (positive) value of a signed long int, and suddenly our system clocks (on POSIX-compliant, and even some/many non-compliant UNIXish systems) will wrap around to, well, the turn of the century. This is *precisely* what the fear was with Y2K, just further in the future. And this isn't theory based on a couple systems, this is a real fear, because POSIX compliant systems WILL do this. Fortunitely we have ~36 years to solve this problem.

The first solution, and probably the cleanest, is to go to 64bit systems, this transition is just beginning, but personaly I think it will be complete within 30 years... ancient business systems might still have something to worry about (as with Y2K) but I doubt it.

The other, not-as-clean-but-quick-and-simple, solution is to bump the variable holding the time to a signed long int. This could be done by a newbie with a C book, and will allow UNIX time to go to 4,294,967,295, sometime after 2100 (I think it was 2106?). This is a band-aid and doesn't really fix the end problem that what we need is an EFFICIENT dynamicaly allocated int type, but just moving to an unsigned long will buy us time if, for some reason, we haven't fixed these damn problems by 2038.
(I THINK Java has dynamic int variables, but i don't think they're efficient. I'd have to grab an extensive book on Java, and I don't have that kind of time or patience:).

And no, we can't just make infinite-sized variables in our current infrastructure, the first one that got initialized would use all the memory and lock the system :)

Re:A bit easier-to-understand explination.

[dangermouse]

So, that's an excellent explanation of the time_t size issue that'll rear its ugly head in thirty-six years.

But it has nothing to do with the billionth-second issue that this article is about.

'Informative', perhaps, but also 'Offtopic'.

Re:A bit easier-to-understand explination.

[AKAImBatman]

(I THINK Java has dynamic int variables, but i don't think they're efficient. I'd have to grab an extensive book on Java, and I don't have that kind of time or patience:).

Java has the following integer types:

byte: 8 bits
short: 16 bits
int: 32 bits
long: 64 bits

All types are signed and are actually quite efficient on most machines. Dates are not a problem either as they are calculated as the number of milliseconds since January 1, 1970 and stored in a long integer. This gives us several million years breathing room. :-) On top of that, we don't have the many incorrect date results (e.g. The leap year in 2000) due to the fact that the Date and Calendar objects were designed by experts in chronology. Check the JavaDocs sometime and you'll find a complete disertation on time and how it is tracked.

Re:A bit easier-to-understand explination.

[Ben Hutchings]

There are so many errors in this that I find it very worrying that it ever got a score of 4.

• There are several other integer types in C and C++, in particular plain 'int' and 'unsigned int'. These are often equivalent to the corresponding short or long types, but this is not necessarily so.
• The bool type is specific to C++, and it holds a single bit. The number of bytes used for its representation varies between implementations.
• The number of bytes used for a 'long int' also varies between implementations.
• The type that time_t is typedef'd to be also varies between implementations, but it is true that on Unix it is generally a 32-bit signed integer.
• Consequently it is not necessary to use a 64-bit system; only to change the typedef for time_t. Unfortunately this will break a lot of code that was written with the assumption that time_t means int or that it means long or that it can safely be converted to and from that type. Such assumptions were never valid.
• I think you mean to change time_t to be an unsigned long int. This should work since this type is guaranteed to hold at least 32 bits. Unfortunately it would also break a lot of that code written under invalid assumptions.

Re:A bit easier-to-understand explination.

[CaptainCarrot]

And if you're only going to store a single byte (such as 1 or 0) there's usualy something like the int type "bool", a 1-byte long int, that allows a 1-byte value to be stored (technicaly this value could be 0 to 9, I'm not sure if negatives are allowed).

Um, no. A byte (I don't think I've ever seen a signed byte, although there's no reason why you couldn't have one) can range from 0 (0x00) to 255 (0xFF) on systems with 8-bit bytes. That's most systems now in use, including the computer you're likely using right now. I first learned to program on a DECsystem 10, which had 36-bit words which were (usually) considered to be 6 bytes of 6 bits each, although there was no hard-and-fast rule requiring this. In MACRO-10, bytes could be of arbitrary length up to the size of the word. Naturally we tended to work in octal rather than hex because a single byte could be expressed as a two-digit octal number from 00 to 77 (63 dec). Yes, there was a fairly limited character set, but in those days you were usually working in all-caps anyway.

Now I work on VMS systems, which effectively do not have date issues. Neener-neener, O Unix freaks!

The other, not-as-clean-but-quick-and-simple, solution is to bump the variable holding the time to a signed long int.

You of course meant to say an unsigned long int. That wouldn't work for the reason others have mentioned: -1 is reserved as an error return. Yes, you could do it and come up with some other error reporting mechanism, but there's a whole big bunch of code that would have to be rewritten to take advantage of it.

Re:A bit easier-to-understand explination.

[timster]

A signed 8-bit type allows values from -128 to 127, if two's-complement notation is used (as it always is these days). That makes 256 total values. (There is no negative zero in two's-complement).

Re:A bit easier-to-understand explination.

[Ben Hutchings]

My understanding was that "int" was always "short int", though yes, it's entirely possible for this to change between compiliers.

int is never the same as short int, in that they are always distinct types for purposes of e.g. overload resolution in C++. On a 16-bit machine they are normally both 16-bit (the minimum allowed by the standards). On a 32-bit machine, int is normally 32-bit.

on the bool, yes, I was braindead on that one as far as the bit/byte thing was concerned, as for bool, are you sure only C++ has it? I thought ANSI C had bool

C99 includes a _Bool type, and I think including <stdbool.h> gives you a typedef for bool. But there isn't a built-in bool type. Maybe that's splitting hairs.

long int bytes, I didn't know this ever varied, I thought it was defined by the standard

The standards specify the ranges of integers that must be representable by each of the various integer types, which in effect require short int and int to have at least 16 bits and long int to have at least 32 bits (and the same for their unsigned counterparts). That doesn't mean they can't have more bits. Nor does it require that bytes have 8 bits. (On DSPs it's not unknown for all the other integer types to have 32 bits, which means they have 32-bit bytes. (Byte = char.))

time_t typedef, does POSIX not specify that it's a 32bit int? I don't exactly have the cash to order a copy of the standard

POSIX might say that time_t is a 32-bit integer; I really don't know. If so, then POSIX needs to be changed at some point.

for breaking a lot of code written under invalid assumptions, yes, I'm aware this is possible, but that code is arguably already broken and should be fixed.

Agreed - but an OS vendor or distributor cannot take such breakage lightly. Users don't want their programs breaking, and if they break when the OS changes, guess what they'll blame.

Yes, but...

[einhverfr]

Have you ever programmed in C?

Leading zeros change things... 031 != 31

031 == 25....

The reason is that C interprets the leading 0 to be an indicator that the number is written in octal.

(Why do programmers always get Haloween and Christmas confused? Because Oct(31)==Dec(25))

Anyway, leading zeros are not always the answer...

Actually 4Gigaseconds is the largest for 32bit

[cculianu]

4Gigaseconds is the larges for 32bit ints. However, I'll bet 50% of the programs out there use a signed data type.. :(

No problems here...

[edashofy]

...I run Windows :)

my propane grill...

[neitzert]

My propane grill died about 1 minute shy of the Billennium causing me to pan fry burgers for our Epoch party...

Oh?

[Dwonis]

dwon@zed:~$ echo -e '1000foo\n999bar' | sort
1000foo
999bar
dwon@zed:~$ echo -e '1000foo\n999bar' | sort -n
999bar
1000foo

billenium non-bug

[Paolomania]

one of my perl scripts that sorted some stuff via timestamp broke over the billenium because i was using "cmp" instead of "<=>". silly me.

Java dates

[SuperKendall]

Java already uses 64-bit longs to hold date values (max value 9223372036854775807), in fact for fun once I made the case in an app that we should allow five digits for the year field to avoid the coming Y10k problem...

Java does have dynamic int classes like BigInteger, but I think they would be too inefficient for something with such widespread use as dates.

My employer got bitten

[Glorat]

My very major company whom I am working for this summer got bitten. They had to release an emergency turnover/fix to fix it. Apparently, they got stuck with an old version of the Perl Date::Manip library (version 1.33 I believe)

Apparently, this version of the library could not perform the "epoch" for seconds beyond the billenium and would report a year 1000 years too early! Of course, this bug was fixed in 1.34 and in fact the current version of Date::Manip is 1.40. Unfortunately, this company doesn't update as often as it should since upgrades can break backward compatibility and need extensive testing. But there you have it, a top company got bitten!

Damn, I missed it.

[Dolly_Llama]

I guess I'll have to start planning early for the next party in 2032.

Re:A bit easier-to-understand explanation.

[CaptainCarrot]

I didn't say it made sense, I'm just reporting what time() is actually documented to do. Personally, I can't imagine, nor have I ever experienced, a situation where the system time is inaccessible. But time() allows for it, and it says right here that you get -1 back if there's an error.

You can also pass in an address for a location for time() to write the time to besides returning it as the function value. Perhaps the error results if you pass in an invalid address? Maybe?

My stomach!

[swordgeek]

My stomach broke as a result of the 1-billion second turnover. Of course, I _did_ celebrate with lots (and lots) of Thai curry...