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

[heytal]

A Simpler solution is to change 999999999 to 0999999999 and then it would sort correctly..

Re:really small stuff

[Anonymous Coward]

Ah, this proves the point that people must have written extraordinarily bad code to get caught to this bug (I'm not directing at you, I've done worse). Thats the advantage of these "rollover" bugs. All the hastily coded apps come out of the woodwork.

If you insist on using the filename to find the recent file, you should have set it up to find that 1,000,000,000 is actually a bigger integer than 999,999,999 .. rather than relying on a rather funky sort.

Why dont you check the file timestamp instead of the file name? I assume you have a valid reason such as the file getting transported around?

Re:really small stuff

[KFury]

Yeah, that.

Re:really small stuff

[Danovitsch]

I suppose you used something like this for sorting the files:
ls |sort |tail -n 1

Than the solution to get it working ALWAYS, is very simple:
ls -t |head -n 1

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

[Grail]

Or just use ISO-8601 format dates, and your problems won't show up until 10000AD :)

2001-09-10T18:36:40

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

[beardcz]

and what (exactly) is 09 ???

Re:really small stuff

[markbthomas]

a syntax error.

Re:really small stuff

[G-funk]

09 is not a valid number.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17....

01 02 03 04 05 06 07 010 011 012 013 014 015 016 017 020....

0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xa 0xb 0xc 0xd 0xe 0xf 0x10 0x11 .....

Geeze, this is news for nerds, you guys should know how to count :-)

Re:really small stuff

[WzDD]

Very easy actually: ls -s |sort -n

Re:really small stuff

[Anonymous Coward]

Uhhh, no, 13 == 013 == 0000000013 in decimal. All of the time sorting shit is in decimal.

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

[Mad Marlin]

I always preferred:

#1b #10b #11b #100b ...

#1o #2o #3o #4o #5o #6o #7o #10o #11o ...

#1d #2d #3d #4d #5d #6d #7d #8d #9d #10d #11d ...

#1h #2h #3h #4h #5h #6h #7h #8h #9h #ah #bh ...

Go HP calculators!!!

Although I would probably make it #h123 style instead of #123h if it had be me who set it up, that would make parsing the numbers easier.

Re:really small stuff

[Anonymous Coward]

Excuse me whist I slap around my fellow AC...

It was a joke. 013 in C is the notation for 13 octal, just like 0x13 is 13 hex. It is nerd h-u-m-o-u-r, it doesn't have to be funny. That explains the joke you never got: why can't a programmer tell the difference between Halloween and Christmas?

Because OCT 31 = DEC 25

ROFLMAO

Now get back in there and disgrace Cowards no more.

Re:really small stuff

[h2odragon]

name files like: YYYYMMDD

no rollovers for a while. Sorts correctly. Fits old filename conventions. Intelligible for humans.

Re:really small stuff

[eep0ck]

yea!!!!

Re:really small stuff

[Nailer]

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

Re:really small stuff

[MrResistor]

I thought 011 was 3...

Re:really small stuff

[Anonymous Coward]

Nope, that's 011b.

Re:really small stuff

[MrResistor]

Right you are!

silly me...

unfortunately

[Anonymous Coward]

the clock didn't break the 'first poster's' computers. Why wont the millenium-schmillenium-bug ever actually /work/? Do you think we techies would be out of work if all those windows/IIS systems had crashed?? Damn.

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...

[Anonymous Coward]

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

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...

[Anonymous Coward]

are you by any chance sarcasticly describing slashdot?

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 :-)

Re:Oh yeah...

[Anonymous Coward]

Some programmer where I work stored mysql dates as
unixtime too.... quick fix for sorting:

order by from_unixtime(your_date_col)

yes... i broke...

[CSIP]

its just wrong to see a unix timestamp start with a 1 im gonna end up trying to debug a problem that doesnt exist...

Squid access.log

[Bronster]

I know that back when I was young and stupid I wrote something that looked a lot like:

next unless m/^(\d{9}\.\d{3}) +(\d+) (\d{1,3}\.\d{1,3} ....

Thinking that that would be more accurately representing what's in the file. Luckily I know for a fact that that tool is no longer in use (a pity, it did very nice nearly-real-time accounting of user per user (mapped to logins with Samba per IP) from ipchains and squid logs).

Hopefully it will be mainly little tools written by college students with a perl manual and no clue *raises hand* that break, and not anything that's in serious production.

My tool would of course just skip every line, and hence it would look like there was no use. Because ipchains traffic would still be recorded it might even take some time for the admin to notice a problem.

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.

Re:older Kmail (from KDE 1.x) billenium bug

[frisket]

Yep. Sucks. I'm running RHL 6.2, and for external reasons can't upgrade to 7.1 yet. So I can't install
KDE 2.2 which contains Kmail 1.3 because it requires 432 gazillion new libraries, and they don't supply a drop-in replacement for the kmail binary to fix the bug. So much for compatibility and upgradability. I just ditched kmail on all machines and started using the mailer inside Mozilla -- but their email import hasn't been written yet...and it looks suspiciously like Moz uses binary-format mail files which is plain ridiculous. So who's got a recommendation for a decent POP mailer...

///Peter

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

[Anonymous Coward]

I was sure this was offtopic but then I noticed that the same post have been posted 1000000000 times before which brings it right on topic. Good work.

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.

Re:broken CVSup on FreeBSD

[macsuibhne]

CVSup was broken, period, not just on FreeBSD. The OpenBSD folks apparently discovered it first, according to the XFree86 developer mailing list. The author, John Polstra, who happens to be a FreeBSD developer, has made fixed binary packages available for FreeBSD 2.2, 3.5 and 4.x in pkg_add format here, along with fixed binaries for Red Hat linux 6.2 and Debian GNU/Linux, requiring a manual install, and the source for those with other OSes.

Hope this helps.

Tony.

Well, stuff NEARLY broke

[xcomputer_man]

1. For one thing my monitor nearly shattered from the torrent of flood that was flowing into #billennium. I live in Houston, and yet I've never seen that much flood in my life.

2. At the very instant the clock rolled over, I got an error message from Ximian Evolution. I think I ought to file this one under bugzilla...

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?

[xcomputer_man]

By my projections, by that time all existing 32bit computers will be in a museum somewhere, which would promptly go out of business...

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?

[pe1rxq]

That is only the maximum of a signed integer,
unsigned integers go twice as far (somewhere around 2106)

Jeroen

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?

[noc]

Ah, but 64-bit processors aren't a full solution. They solve the source of the problem, but I'm sure we'll find all sorts of odd 32-bit assumptions and "clever" things wrt keeping a handle on that number-of-seconds-of-unix. Hopefully it'll all add up to a small problem, though

Re:Anything Break?

[Per Wigren]

Since 8-bit computers are still in use today we can't just expect all 32bit computers to be gone by 2038!

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?

[oli_freyr]

It's funny to note that the list you mentioned doesn't include the billion second date...

That must mean they're all just making this up ;)

Re:Anything Break?

[Anonymous Coward]

Hey, I bought a Sega Mega CD II

Lethal Enforcers *click*

I'm going in...

Re:Anything Break?

[oops]

I used financial systems which handle bond expiry as no. of seconds in 1970. These systems will have problems in 2008 (not that far off in the future for a core banking system) when you try and enter the expiry date as being 2038.

I've seen this already where the systems simulate a non-expiring bond (for analytical purposes) as expiring way off in the future, and the furthest they can get away is 38 years (and closing)

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?

[Idolatre]

And what about databases that store dates BEFORE January 1 1970 (in unix time format)?

It's like the Y2K solution of making anything = 50 19xx, it's a patch rather than a true fix

And you'll have to recompile everything, but the source is not always available (maybe not for must publically available linux software, but there are lots of closed source proprietary specialized applications)

Re:Anything Break?

[TeknoHog]

I'd really like to know what the original designers were smoking when they decided to represent time_t with a signed integer. But then again,

31 bits should be enough for everyone.

Re:Anything Break?

[Bj�rn Stenberg]

And what about databases that store dates BEFORE January 1 1970 (in unix time format)?

They belong in the 'fubar' category. time_t was never intended for database use, and shouldn't be used for dates before 1970 either. Read the POSIX spec:

2.2.2.77 seconds since the Epoch: A value to be interpreted as the number of seconds between a specified time and the Epoch. ... If the year < 1970 or the value is negative, the relationship is undefined.

You can make anything break given enough foolishness.

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?

[Bobo the Space Chimp]

This isn't a troll, it's a brilliant comment. Where's my metamod whackstick...

I am not a unix guru (well, not to the full 32 bits, anyway) so I'd like to know what the original designers thought when using 31 bits, what was the last one reserved for?

Re:Anything Break?

[Bj�rn Stenberg]

The idea was to have a time format that spans the entire 20th century (almost, it starts at 1901-12-13 20:45:52) and some of the 21st.

Eventually, The Bearded Men of POSIX decided that negative time_t was a bad idea, yet they kept the variable type signed. Probably they just chickened out in fear of breaking existing systems. :-)

Re:Anything Break?

[NNKK]

The point is that for some reason, signed long ints were used instead of unsigned.
Why they were that braindead, I do not know.
Maybe they needed it to work under negative numbers before the system was activated as production? I'm pretty sure work on UNIX began shortly before 1970.

Re:Anything Break?

[russh347]

And most of them don't know or care what day it is...

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?

[IvyMike]

There's a really extensive one at http://www.merlyn.demon.co.uk/critdate.htm

That's the one I remembered; thanks!

Re:Anything Break?

[Dr. Evil]

But some of them do...

Re:Anything Break?

[Idolatre]

But I guess storing the year as 2 digits instead of 4 was never intended for a database too, but it didn't prevent it from being a widespread way of storing the date in a database, causing the whole Y2K paranoya(?)

Re:Anything Break?

[poot_rootbeer]

Simply changing time_t to an unsigned int is a great solution, if nothing happened before 1/1/70 that your computer needs to know about. That's a pretty large assumption to make.

37 years from now, how many *nix-based systems will still be running on 32-bit processors? How many systems do you think will still even be running a *nix in 37 years? 4 decades prior to right now, people were marvelling at how you could type words on the keyboard of your spankin' new PDP-1, and they'd show up on the CRT screen.

-Poot
(Actually, I'm just hoping to rake in the big bucks as a "S2^32" Conslutant in a few decades.)

Re:Anything Break?

[sethanon]

Well, I personally know of quite a few PDPs still in use in industrial settings. I don't know the age of the particular machines I was working on but that model is 31 years old.

Heck, we had to reconfigure a few things last year and one of the configuration files I was updating hadn't been modified since 1991.

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.

Re:Anything Break?

[Anonymous Coward]

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.

So reserve the *last* 4095 positive numbers instead, I'm sure nobody will mind losing 68 minutes soemwhere during the year 2106 ;-)

Re:Anything Break?

[Anonymous Coward]

• By that time all existing 32bit computers will be in a museum somewhere

Tru64 Unix: 64 bit OS on 64 bit Alpha CPU...:

time_t is a 32 bit signed integer... :-(

Isn't the specification for time_t part of the Unix(tm) spec?

And to the 'just make it 64 bits' croud -- you will have big problems with older binary datafiles that use 32 bit storage... Just like the problems with 2-character storage for Y2K...

Re:Anything Break?

[Anonymous Coward]

Unless you wanted to look at Dec 31, 1969!! Date has to stay as a signed int.

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...?

Re:A possible connection?

[jdigital]

so did eddie mcguires house.
read story here

Re:A possible connection?

[Anonymous Coward]

Are you suggesting Unix powered letter bombs?

Or something more sinister?

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?

Re:An entire HD

[ChazeFroy]

Apparently older versions of eggdrop bots (an IRC bot) have had date problems.

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

[Anonymous Coward]

Thats most probably due to the program using the autosort routines from KDE or QT where they do alphanumeric sorts on a numeric field where the 99 timestamp will be bigger than the 10xxx stamp. Gtk+ proggies like Pronto! also suffered from the same problem but was fixed by hooking a different sort function that distinguishes numeric fields from alpha fields.

Re:knode

[Anonymous Coward]

kmail AND knode.

What is it with KDE and poor software quality?

Re:knode

[Anonymous Coward]

Will be fixed in KDE 2.2.1 available next week.

Cheers,
Waldo

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

distributed.net?

[FyRE666]

Just took a look at my stats on distributed.net this morning, and something definately looks screwed over there. Yesterdays stats for the Slashdot team look somewhat strange too :-)

IkonBoards are down

[Johnso]

One of the most popular webboards suffers due to this error. Read the fix: here.

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/

Re:really small stuff (RTFM)

[Anonymous Coward]

sort -n

(Sorts numerically, so 1000foo is after 999bar)

Cheers,

--fred

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.

[smallpaul]

As a Python bigot (flame-bait me!) I'll point out that Perl, PHP and a few other Unix-y scripting languages are especially prone to this problem because they don't distinguish between strings and integers. I always knew that there would be a payoff in Python requiring me to explicitly convert.

This seems like a cheap shot but really there is a systemic issue here. Perl trades robustness for succintness whereas Python tends to require you to say what you mean explicitly. With perfect programmers there would be no difference. In the real world, programmers are not perfect and a language that helps you to find potential problems can yield quantitatively more robust code.

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.

[Grail]

You got moderated to 3 without providing any examples?

Perl does distinguish between strings and integers. Just try using ("foo" == "foo") in a comparison and see how far you get.

Please supply an example of where Perl's "non-string-discriminatory" behaviour gets it into trouble.

Sometimes you have to be specific, and tell Perl to do comparisons as numeric operations:

my %hash;

$hash{23} = "first";
$hash{126} = "second";
$hash{246} = "third";

foreach my $item (sort {$a <=> $b} keys %hash) {
print $hash{$item} . " ($item)\n";
}

That's because Perl is a text-processing language that knows how to do math, not because Perl is especially prone to S1G bugs! Yes, your comment is a cheap shot, because due to your Python bigotry you assume that anything that isn't Python is flawed.

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.

[bharatman]

Get your facts straight. Emacs compiles into byte-code. Perl compiles into byte-code. So does Python, Java, etc.

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.

[crazney]

hey muhri, http://slashdot.org/~muhri/ - dont know what email adress u used, but whicher it was youll have to get the domain admin to grab the email for you :)

Re:My mail client - pronto broke.

[Fruit]

The problem he mentions is quite relevant. It is the same problem as described in posting #2272404.

Re:My mail client - pronto broke.

[AstroPup]

The bugs I've seen didn't have anything to do with allocation of enough digits (although I'm sure there are plenty). The most common bug is programmers sorting the date lexically so that any billion+ date stamp gets put at the bottom of a sort because 1 &lt [2-9].

Maildir stores it's messages in files with the format [timestamp].[pid].[host]. Pine, Mutt and others sort on date lexically. All new messages are showing up in the wrong place when sorted by date.

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.

[Anonymous Coward]

> My sig annoyed people to much, so its gone.

That's because it contains two grammar and spelling errors.

1. "too much"
2. it's gone

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.

[stripes]

Emacs compiles into byte-code. Perl compiles into byte-code. So does Python, Java,

Actually perl can be "compiled" into C, and then a native executable. There are also Java to native compilers (see current versions of gcc), as well as incremental Java compilers that make machine code. I don't know about Python, and I'm pretty sure there isn't anything more then byte-coding for elisp, 'tho there have been projects to make it machine code in the past.

Re:My mail client - pronto broke.

[Zero__Kelvin]

It is starting to cease to amaze me when I see ludicrous and uninformed posts like this get rated in the 3 to 5 range. No competent programmer does math on strings when scalar values are appropriate. 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. If you don't know the difference, learn.

Now here is the kicker. You actually wrote "You're not flamebait because you're a Python bigot, you're flamebait because your post is an invalid rant and off-topic"

I once tried to explain irony to somebody on Slashdot. If you happen to see this, it is a shining example therof.

Finally, the only thing you said that has a modicum of truth to it is this (though I will use my own wording here)... no matter how good your data manipulation routines are, if your persistant storage mechanism loses data, things are going to be a mess. So yes, if you do everything right, but store your whole document in a char (the fact the your dbEngine allows this is yet another matter ... but I digress) you will not have much luck retrieving your document and displaying it exactly as before.

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.

[NitsujTPU]

In their native enviro, java bytecode runs on a "virtual machine." Uhmm, yeah, that's an interpretter... Perls bytecode runs through an interpretter. Hrmm, yeah, I guess that's right. It's not meant to smack down on the language, and people get all defensive about this. I mean, hell, byte compiled emacs stuff isn't the same as byte compile C if you want me to be a dick about it. I'd like it to run in machine code if I can. Not to be rude, but there IS a difference.

Re:My mail client - pronto broke.

[Zero__Kelvin]

In Perl, a variable preceeded by a $ is scalar. A variable preceeded by @ is an array. Add a scalar to an array and Perl will cast it for you. It is up to you to know HOW to tell your language to use scalar math (in this case store both your variables as scalar to avoid implicit type casting) That's the problem ... not with perl ... but with the state of the industry. Perl makes a fine language if you already know all of this stuff cold. It does nothing but confuse those who don't, and so mis-informed people moderate other mis-information up and the problem is excacerbated. Perl quite explicitly 'tells you in time' about all this. You don't even have to wait for a runtime ... it's in the language specification.

Cheers,

Zero__Kelvin

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?)

Re:My mail client - pronto broke.

[wimmi]

We had an application which read some results from a MySQL database and it was stored in a Perl hash.

It took a while before we found out it was stored 'literally' instead of numeric:

$VAR = {
'key' => '23232222',
'key' => '333221222',
}

Which of course didn't do a proper numeric sort.
Now we had to explicitly define the value part of the hash numeric.


$VAR = {
'key' => int($var),
'key' => int($var2),
}

Which fixed the trick. I'd assume that Perl would figure numeric MySQL fields is implicitly numeric.
Oh well, earned another day's wages at the job! ;-)

Re:My mail client - pronto broke.

[GreyPoopon]

See http://slashdot.org/comments.pl?sid=21493&cid=2272 567 [slashdot.org]. The problem is in GTK+'s sorting algorithm (alphanumeric)

Yeah, I saw this after I posted. But the general argument is still valid.

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.

This is true. However, I want to clarify that a strongly typed language doesn't necessarily make a better programmer. Using a strongly typed language as a beginner might help because it will teach you some basic rules. But in general, all the strongly typed languages do is reduce the number of runtime errors by catching some of them at compile time. No matter what, there's still room to shoot yourself in the foot.

billenium bug

[Anonymous Coward]

my car wont start now, i just know its caused by the billenium bug

Re:billenium bug

[Anonymous Coward]

Fool. That's what the jews want you to think! ;)

(for those offended please replace "jews" with "masons")

Concorde Travelling-Salesman solver

[eigenkarma]

Concorde is a nice package for solving travelling salesman problem. It has a fast implementation of chained Lin-Kernighan heuristic. I've been using it extensively in the last few months and starting this morning (Australia time), it's been crashing randomly, even when applied to the same data that worked fine last week. I recompiled it on various unices (Linux, DEC) and same thing still happened. Because the program uses random number extensively to create new paths, there must be something wrong with the way it generate the seed. Luckily, it has an option to fix the random number seed, and when it automatically chooses one, it also displays it.
Looking at the numbers, it's not hard to make the connection.

Re:distributed.net? - Fixed...

[FyRE666]

Oops! Looks as though whatever was wrong is now right again. It was screwed though, honest!

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 ?)

Re:Canon S10

[Anonymous Coward]

Don't know what's up with you, but mine's fine. I assume you're talking about Zoombrowser EX? All my pictures have the correct dates in there. I just took a picture on the camera, and it shows the correct date, too.

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!

Re:OpenLDAP slave servers completely broken

[Anonymous Coward]

Me too guy, we've got at least 30 servers which were bitten by this .. 20 mail servers had to be re-synced :(

I am not impressed ...

Re:OpenLDAP slave servers completely broken

[wjodon]

We came into work this morning to find that we had this same problem. We also found that you do not have to patch your code immediately to work around the bug.

The quick fix is to delete the slurpd.status file, which is then replaced by a slurpd.status with a 1G+ time which will compare properly using openldap's strcmp expression until we hit the S10G threshold.

We do plan to upgrade at some point before then, since we will all have moved on or retired, and nobody will be left who remembers S1G *grin*

Re:OpenLDAP slave servers completely broken

[AKAImBatman]

Can't you just touch the old file?

Re:OpenLDAP slave servers completely broken

[wjodon]

No. Slurpd uses a date contained with the file, not the date of the file itself, which you'd know if you actually cared and weren't just being a weenie.

Funny buisness

[haroldK]

There are some funny goings-on with BeBS (a Cit-86 style BBS package that runs on BeOS) 2.0 test2 that happened after the rollover. Rooms are reporting incorrect numbers of read/unread posts and some various functions are just plain funky. Luckily, 2.0 hasn't been released and the author (my friend) has a couple test boards up to check all this stuff out, but it's been interesting checking out new posts.

Oh, and I'm sure he'll appreciate a link to the board if anyone wants to help with beta-testing.
http://bebs.net/
telnet://bebs.net:8088

"illennium" and other overused words..

[Desiato_Hotblack]

Anything with "illennium" in it should be taken out in the over-hype word pasture and be shot.

We (as in most IT people in some support role or other) have put up with this useless combination of letters since the whole Y2K overblown mess, we don't need to hear about it again for quite some time, thank you very much.

Am I cranky? Sure, but I thought there would be a better choice of words than some puff-pastry attempt at commemorating the billion-second turnover. Too late now, you've already ruined it.

Hotblack_Desiato

Re:"illennium" and other overused words..

[Desiato_Hotblack]

You said (edited):

shut up you [expletive, expletive], and get back on the phone. there are people running win95 who need your help to get online.

Nice try, but when I meant support, I meant much more than "helldesk". Of course, you are too busy posting one-liner hate messages than paying attention to details.

Perhaps next time when you are posting from your storebought system and dialing up with your 14.4 modem, you might stop to think that your nickname and homepage (which, by the way just shows how dumb you are if you claim to hate black people) is not the best way to prove to the world you are a buffoon. Wait, correct that -- a hate-mongering buffoon.

Thanks for playing, and yes - I would like fries with that you minimum-wage joe compaq.

Desiato_Hotblack

Re:"illennium" and other overused words..

[Desiato_Hotblack]

You opened your mouth without thinking and bleated:

You sure are one angry helpdesk Jew!

Last I checked, "Desiato" had italian origins - but I chose it for entirely different reasons which would be apparent to people who read books, a group of which you obviously aren't a member of.

Thanks for playing, but BZZZT! you lose, again..

Hotblack_Desiato

Re:"illennium" and other overused words..

[jo44]

I think this whole thread should be modded up and marked funny.

BTW, N.R.S., nice sig.

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 > .

I thought I missed a party there...

[ayjay29]

When Anonymous Coward wrote "The billennium party at OpenProjects.Net rocked!" I thought thay had organised some major event, with music, drinks, party food and maybe even a chick or two. I checked out the link and it's just a bunch of nerdy unix guys talking crap on IRC, what a dissapointment.

If the open source movement is ever going to get anywhere they need to know how to throw a good party.

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

[Anonymous Coward]

Hell I was at the GameSpy party at E3 two years ago and frankly, geeks just don't DO "regular parties!" It was a nightmare... a completely empty dance floor surrounded by people talking about computer stuff. The poor DJ couldn't figure out wtf the problem was...

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.

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

[Anonymous Coward]

This is andy, the OPN ircop... I had a bunch of friends over (read 20), and it was just like that... BYOB, but still, great stuff. :)

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

[castanaveras]

Well, the next opportunity for a *nix time party will be when time_t = 1234567890, which will be (gmtime): Fri Feb 13 23:31:30 2009. So we've got eight years to prepare :-)

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

[wayne606]

At a USENIX in 1993 or some year like that (it was in San Diego) they had a professional stand-up comic who was trying to entertain the crowd. He had actually wandered around beforehand and picked up some jargon and tried to make his jokes relevant but it was pretty lame (something about RMS never taking a bath is all I remember). Eventually he got really annoyed with all the people shining laser pointers at him. Just goes to show ... not sure what ...

Yeah, some of my older programs broke

[Anonymous Coward]

When I was first learning PHP/MySQL I stored some timestamps in varchar() fields in MySQL. Apparently when I do a "select * from mytable order by timestamp desc" it counts 1 billion as LOWER than 999999999.

All I did to fix it was convert all the fields to int fields and everything started working again. Argh I really should rewrite those scripts anyway.

Re:Yeah, some of my older programs broke

[Anonymous Coward]

And with PHP being not strongly typed, you don't need to change any of the app.

(See the flamage above over Python vs perl)

Re:Yeah, some of my older programs broke

[Anonymous Coward]

sure, or here's a crazy idea -> use a timestamp, moron.

Here's something that broke....

[kndnice]

http://shack.mine.nu/billennium.log

Re:Here's something that broke....

[lposeidon]

damn it windows broke again... but thats irrelevant.
its afraid of the billenium :)

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*

12 years of school over - anything learn?

[Anonymous Coward]

Hmm...

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?

[Anonymous Coward]

You bastard, I'm already god!

Re:Anything Break? DID YOU NOT NOTICE?

[dimator]

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

[bows head]

Re:Anything Break? DID YOU NOT NOTICE?

[madcow_ucsb]

I think a fight to the death is in order...

Re:Anything Break? DID YOU NOT NOTICE?

[c0rtez]

Easy way to remember where the door is:

Order a pizza; listen for pizza man knocking to find the door.

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

Re:Maildir-based IMAP server broke

[Anonymous Coward]

It's the UW c-client library with maildir patches. I'm not running IMAP, but am using pine against Maildir, and it's broken in exactly the same way.

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.

Re:Notice about seconds overroll

[SilentChris]

Note to self: do not accept bug reports from people who can't speak English. :)

Re:Notice about seconds overroll

[Anonymous Coward]

Yep, that's exactly what happened to me. Luckily I read about the rollover here a couple of days ago, so it only took about 5 minutes ( well, 15 :) ) to identify the bug, and then an hour to modify the tables.

Here's an example line ( for a table named "sessions" with a timestamp field named "starttime" ) I used to "fix" the tables, in case anyone needs it:

alter table sessions change starttime starttime int(11) NOT NULL default '';

( Don't forget to backup your tables before doing this though...of course )

And, yes, I do feel like a dork for getting this wrong in the first place; we have 64,000 people in our community ( http://www.wizardmansion.com [ okay, a shameless plug, I know ] ), and they were up in arms all day Sunday. :(

- thomas

Re:Notice about seconds overroll

[raynet]

Ah, when will people understand why there is a time,datetime,timestamp etc. types in databases (dunno if MySQL has them, PostgreSQL has :) It is so easy to say:

INSERT INTO blah (data,timestamp) VALUES ($data,'now()');

or even simpler if just define that default for timestamp (or what ever you use) is now() (or similar).

This way things will broke when you run out of bits. Or use datetime, it holds time values between 4713 BC and AD 1465001 at microsecond resolution, that should be enough for anyone :P

Re:Notice about seconds overroll

[Anonymous Coward]

Note to you: go fuck yourself.

Re:WHAT THE FUCK IS YOUR PROBLEM ??!!

[holloway]

Hell. Yes.

Break? well.. SWAT broke in.

[Anonymous Coward]

We celebrated epoch + 1e9 with firecrackers. 1.5 - 2 hours later we discovered how much of a bad idea that was. The local anti-terror police (I guess it can be translated to SWAT) came busting in our door - neighbours had reported hearing gunfire.

And the norwegian police don't usually come busting in peoples homes with armed rifles :)

Tonight I'm gonna party...

[Salsaman]

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

(Shamelesly ripped from ntk.net).

Re:Tonight I'm gonna party...

[Salsaman]

Before anyone corrects me, it should of course have been:

(time_t) 1E9

Re:Tonight I'm gonna party...

[will]

(Shamelesly ripped from ntk.net).

who shameless ripped it from london.pm.

watch out!

[lobiusmoop]

in 30 years time, UNIX will become confused and uncertain as it reaches is dilemma-umm.

Legacy Eggdrops

[Bostik]

I know of at least two older eggdrop bots that went broke. There was a nasty bug in older eggdrops that just assumed a 9-character uptime calculator.

This page shows what versions were affected. Yes, there were quite a lot of 1.4.x 'drops still around...

Re:Legacy Eggdrops

[Anonymous Coward]

1.6.4 is affected, you can fix it from the config file but it's recommmended that you upgrade to 1.6.6 (which I did). bseen broke thats how I found out :)

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?

things broke

[OpCode42]

Our exchange server crashed, and the WINS servers were acting really strangly. Dont think it had anything to do with getting to 1,000,000,000 though :)

Re:things broke

[Anonymous Coward]

>and the WINS servers were acting really strangly.

Did it start working properly? That would be about the strangest thing I could imagine.

Cup holder.

[gdr]

My cup holder broke, does anyone have tech support's phone number?

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.

Re:Veritas Netbackup

[ayden]

From the Veritas TechAlert:

SYMPTOM
When browsing files or directories in the "Backup Files" tab of NetBackup with the JAVA Client GUI (only), any file or directory created after September 9, 10:46:SS will display an erroneous date of 1973. This erroneous date will also display in the "Task Progress" tab for any backup, archive, or restore which was initiated after September 9, 2001 10:46:SS.

Although the dates presented on the "Backup Files" tab and the "Task Progress" tab will be incorrect in the cases stated above, it will NOT prevent user backups, archives, or restores. In addition, this problem does NOT affect the "Restore Files" tab. The dates on the "Restore Files" tab will be the actual date and time the files or directories were last modified and backed up.

WORKAROUND:
VERITAS recommends installing the patches identified in TechNote 239940. Below is a link to navigate to this TechNote. There is a temporary workaround to correctly display date(s) and time(s) when browsing files and directories. This workaround is to utilize the Motif GUI, command line, or bpadm interface instead of the Java GUI.

PERMANENT SOLUTIONS:
For specific details and the related patches for this issue, please navigate to the following link:

http://seer.support.veritas.com/docs/239940.htm

You can also navigate to this link on the VERITAS Support web site. This information is available in the "Patches and Updates" section.

If there are any questions about this issue, please contact VERITAS Technical Support Services for clarification or assistance.

Sincerely,


VERITAS Technical Services

Sony parties used to be good

[Anonymous Coward]

Free vodka, Jarvis Cocker singing, loads of food and playstations running in the side rooms... I Didn't go to this years one though :-(

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

[sirinek]

Mod this up, because it affects a lot more people than you might think.

This problem is a pain in the ass and now I'm using mutt (with its awkward commands that im too lazy to figure out how to change). Here's hoping my ISP updates pine.

siri

Re:pine / UW IMAP

[Deal-a-Neil]

Big pain in the rump. And just so you know, we have a very recent version (4.33L2) running, and it happened to us as well. The fix -- not sure.. but what I did was this:

su user
mv ~user/Maildir ~usr/Maildir.old
mkdir ~user/Maildir
mkdir ~user/Maildir/new
mkdir ~user/Maildir/tmp
mkdir ~user/Maildir/cur
cp ~usr/Maildir.old/cur/1* ~usr/Maildir/cur/

I did this because we weren't getting ANY of the new messages showing at all. This archives the current Maildir, moves the billion-second messages over and allows you to do some post move reconstruction when you have free time. ;-)

Re:pine / UW IMAP

[hico]

Just append a '0' to the filenames starting with '9'
in your Maildir/new Maildir/cur directories, and it's fixed.

I'm going to put together a script to go over Maildirs and do it automagically.

http://hico.fphil.uniba.sk

Re:pine / UW IMAP

[Anonymous Coward]

I'm running Pine 4.33 with Maildir mods. It seems to be a sorting problem, and what I did was add a "0" to beginning of all the 9* filenames.

cd Maildir/foo
for iii in `ls 9*`
do
mv $iii 0$iii
done

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";
}

}

1000foo is not a number

[Hell O'World]

nor is 999bar. So you'd have to split them, sort them, and reattach them.

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. :-(

Grrrr, billion seconds of pain!

[Anonymous Coward]

Old mail system, used strcmp on timestamp to order the mail, decided to completely change the order system as of yesterday. Its fixed, but it wasn't fun.

Oh, I heard Anarchy Online had some billion second problems, or was that there billionth crash, or there billionth excuse, or there billionth parch, it all seems to blur after a while

Training for Python bigots

[Anonymous Coward]

How about we strap him into a chair in a thatre, prop open his eyelids (making sure to use drips to keep his eyes from drying out) and make him watch screens upon screens of Obfuscated Perl Contest winning entries? That would cure him. :)

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.

[bp33]

I'm only replying to this because it's marked as informative, even though there's a bunch of errors in it. The only one I'll point out is:

Discussing '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).

I don't know what you mean by "0 to 9" but any 8-bit storage type can hold eight bits. The values can be 0-255 if one of the bits is not used as a sign bit, otherwise -127 to 127 is allowed.

Type 'bool' is not in the original K&R C, by the way. Waaaaay back before ANSI C, people knew that 'char' meant '8 bits' and that was that - not that it held a printable character. These days, the kidz are overloading the *semantics* of the type with the *storage size* of the type. It's kinda like the purist "HTML as document structure" vs the "HTML as document layout" folks, but I digress.

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

That's not a solution at all. There's a reason time_t is *signed*. It's so that dates before 1970 can be represented.

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.

[Anonymous Coward]

> That's not a solution at all. There's a reason time_t
> is *signed*. It's so that dates before 1970 can be represented.

If you're correcting people, get it right at least. Check POSIX, negative time_t values are undefined. Just because you're misusing time_t to do things it shouldn't doesn't make the hacks you use standard. If we switched time_t to unsigned, and your code broke, that'd be because your code already was broken.

Re:A bit easier-to-understand explination.

[NNKK]

By my definition, it became on-topic when people began talking about the 2038 problem in more than a few comments.

Re:A bit easier-to-understand explination.

[NNKK]

OK sorry, I've never really studied java, and from the conversations I've had with people about it, I was under the impression that java did some sort of dynamic allocation for its ints. Guess they were all just inexperienced :)

Re:A bit easier-to-understand explination.

[NNKK]

My own braindeadness on this is partly at fault here.

I've been looking and I'll have to look harder, but because I don't have a full C++ reference guide (I should pick up the book by the C++ creator, the name of the book escapes me at the moment) I might not find its exact size, however I just tested this:
bool returns "1" with any value but "0", so I don't think it's a "normal" type like char, or any of the "standard/normal" ints, so "char" isn't neccisarily a correct replacement for "bool".
Also there have been discussions as to why it was better to impliment bool than to use some alternative.

As for the less-clean solution, an AC already stated the obvious: negative values for time_t are NON-STANDARD. As such, they should be discouraged.

Re:A bit easier-to-understand explination.

[Anonymous Coward]

Actually, it is signed so that -1 can be returned in the event of error.

Times 1970 don't exist in POSIX.

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.

[NNKK]

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

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

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

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

last two points:
yes, I ment unsigned, I went over the comment twice and still didn't catch it, oops
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. I love backwards compatability when possible, but I'm not a big fan of backwards compatability when it means being retaining compatability with something that has a bug/design flaw.

Re:A bit easier-to-understand explination.

[NNKK]

Can you clarify this again? -1 is used to return an error? in TIME?
can you provide an example where this would be useful? it's probably just me, but I can't really see a real-world use for it...

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.

Re:A bit easier-to-understand explination.

[NNKK]

OK that clears up the ints, thanks.

I could have sworn I read in at least one credible place that ANSI C had built-in bool, guess not.

POSIX, I just don't know what it days, I should probably try to get some cash together to get a copy of the standard. :)

Somebody should put the vendors and distributors on alert to have their software changed by 2025 :)

sort -n

[Rommel]

Consider sorting numerically instead of alphabetically.

voicemail broke

[Giordy]

Our voicemail at work broke...it's running an old version of system V/386. Called lucent, their fix was to change the date back to 1992.

One break

[savrinor]

One of my friends runs a small (500 user) IRC server, and their services went berzerk when the billennium came. Mostly because they were poorly coded and there were problems with g-line times, etc. which are stored in seconds.

Somehow...

[jermz]

It affected my bowling game! See, I was sitting in the bowling alley, waiting for the game to start, when my pager went off, wishing me a happy billennium. My game went to pot.

I really doubt it was my bowling prowess...
;)

Jeremy

NIS on AIX 4.2 broke

[Anonymous Coward]

See subject. NIS on AIX 4.2 doesn't work correctly anymore. I don't know if there's a fix available, IBM's support site is a nightmare if you're looking for something specific.

It sure did!

[GreenBugsBunny]

Nothing big, though. I administer a classified site for automobiles (EZCarLocator -- please don't slashdot it too hard, it's only a virtual host sharing a machine with 3 other sites) and I store the images in userId_AdImageNumber_UNIXTimeStamp.jpg format. Well, the userId's are in the 4-digit range now, and the rollover added one more character than I allowed in my table field, so i lost the 'g' at the end of each new file resulting in a bunch of broken images.

The same thing would have happened if the user id's had rolled over to 5-digits, though. I think it's fixed now (i doubled the field length to 40 characters, now) and it should hold for quite a while.

I guess I'm just fortunate to have a little bit of in-house testing or it would have probably gone un-noticed for quite a while.

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...

Offtopic: Code Blue Worm hits China

[Anonymous Coward]

http://www.newsfactor.com/perl/story/13405.html

Yes! Slashdot's Broken!

[Anonymous Coward]

Or is it Slashcode that's broken?

Or was it broken before the changeover?

Is VAX/VMS affected by this in any way?

[bedouin]

My university still uses VMS/VAX and I noticed as of yesterday, none of my mail is coming through, although I can connect to the POP server. Slowly, this morning, some mail has been funneling through from yesterday.

how do i open this?

[mr100percent]

Sorry, I'm on a windows kiosk, so how do i open this.

I think Veritas NetBackup broke

[Anonymous Coward]

I believe there was a small display problem in the java applet used to display the backup dates. While their doesn't say anything about the cause. I'm sure it too much of a coincidence. Damian

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...

FreeBSD's CVS tool broke.

[ChrisKnight]

Date: Sun, 09 Sep 2001 13:31:29 -0700 (PDT)
Organization: Polstra & Co., Inc.
From: John Polstra
To: freebsd-announce@FreeBSD.ORG
Subject: Update to fix CVSup timestamp bug
Sender: owner-freebsd-announce@FreeBSD.ORG

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

This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org

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.

My NT domain controller broke!

[Pinball Wizard]

But, I have to ask, what does that have to do with the billenium?

Trolls are anonymous

[TastyWheat]

Hey moderators. Trolls are defined as anonymous.
How can you be a troll if your not anonymous.
Apparently u simply disagree with my comment which was on topic btw. U just don't like it.
Take all my karma points. I dont care. Just admit your bias like a godd little slashdotter.

Anonymous cowards and trolls

[TastyWheat]

So an anonymous coward gets an insightful for a butt fuck drawing. Oh god. Must be a bunch of 5 year olds moderating. The term gaywad has nothing to do with homosexulas at all. Your little troll tiff is gaywad for example. The stupid counter rollover is still gaywad. If u don't like my comments then reply. But calling this a troll message is incorrect, as u r actually commenting on my use of the term gaywad, for which u don't even know what it means.

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.

URLs

[Chris.Boyle]

KDE Dot News has a story, and there's more info on KMail's homepage.

Big one here

[Watcher]

Well, we've been in utter hell here at my employer. One of the middle tier objects in our products were hard coded with the expectation that the time would never go over 1 billion. The moment it did, all of our internet products at all of our client sites went bust. We're still picking up the pieces, and will be doing so for some time to come. Yet again I have another reminder to point to of the necessity to design software, not just throw it together like the offending developer did.

Re:Anything Break? YES Big Style!

[Anonymous Coward]

Our company makes mobile data/vehicle location systems for the UK emergency services... we output vehicle location data in a format called Simple Vehicle Location Protocol (SVLP) which is ASCII CSV in the form: POS:,,,,, etc. One of the command and control system suppliers (no names, no pack drill) didnt parse our data correctly [they assumed fixed field width] and broke after the roll-over. Result over 200 ambulances in unknown locations... very sad... especially as they were warned about the problem in advance... still it's fixed now...

AT&T System 25 broke

[Anonymous Coward]

Left the whole office without voicemail.

Qmail Maildir/cur fix

[rimshot]

#!/usr/bin/perl
#Doug Weyrauch
#doug@gogeek.org
#9/9/2001
#This file renames all the mail files in Maildir/cur to the 10-digit number
#since there have now been a billion seconds according to the unix clock.
#And since qmail names its mail files according to this, we need a
#leading zero (0) so that your new mail isn't listed before the old mail
#(at least for pine and some other programs).

use File::Copy;
$dirname="Maildir/cur";
opendir(DIR,$dirname) or die "can't opendir $dirname: $!";

print "Backing up current mail directory Maildir/cur just in case\n";
system("cp -r $dirname Maildir/curbakup");

@list = grep { /^9.*$/ } readdir(DIR);

foreach $item (@list)
{
print "$item will be changed to 0$item\n";
move("$dirname/$item", "$dirname/0$item") or die "copy failed: $!";
}

closedir(DIR);

Zophar.net

[Yukanojo]

Zophar.net, a (the) big site in the emulation community, had a spot of trouble with their cookies... to quote the webmaster: "I believe most of the problems have been fixed. For the nerds, I set the cookie time to expire on "999999999" and we've passed that. Obviously, ZD relies on cookies :)"
Oh yeah, and TastyWheat, CHILL. If you don't like the ratings system then don't post. Of course, here I go earning a "Flame" rating for that ;)

You might be a geek if...

[writermike]

If you say a party "rocked," and your proof of this is a logfile, you might be a geek.

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!

IRC #billennium

[rawg]

The #billennium was cool except for the nazi bastard ops that whined about flooding in a room of 500 people. Bans and Mutes were thrown around left and right. I liked seeing the cowsay with the count down in it. It was so packed that you could not read anything anyway. It was a party dammit. I can see at the end when the servers started puking, but like way way before, that was lame.

Damn, I missed it.

[Dolly_Llama]

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

Re:NERD AS HELL

[Anonymous Coward]

cooking me dinner and fucking me

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?

Re:A bit easier-to-understand explanation.

[NNKK]

simplest possible form of error reporting gives us a puzzler for 2038...
with 36 years to think about it, I do hope this gets fixed before then

I CAN see the invalid address thing happening, so I suppose it does have some merit keeping it as a signed long... but damn....

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...

WHO WANTS TO BE A FIRE VICTIM?

[Anonymous Coward]

Sucked in Eddie, fkn TV host faggot.

Don't forget Unisys

[Anonymous Coward]

Good practice for C and C++ recommends -127 to 127 as the range for signed char to cope with those sad machines that use ones complement. Not every CPU is made by Intel you know.

We still have to deal with those machines. And EBCDIC (thank you IBM).

The standard seems loose on this point (ISO/IEC 14882:1998 3.9.1.2) although you should not specify char (which means a character) when you mean signed char or unsigned char (which mean an integer).

hell what's the problem ?

[Anonymous Coward]

I don't get why all the fuss about ? I still feel good and netscape works great on all XXX sites.

Did anyone do a patch?

[bill_mcgonigle]

Since there are a few hundred thousand people in this particular boat (no me thankfully) here's hoping someone did a patch... Please post a URL here if you know of one.

Windows ME System Restore

[LazyBoy]

http://support.microsoft.com/support/kb/articles/Q 290/7/00.ASP

Anything Break? -- Folding

[Inthewire]

I don't have any reason to be SURE, but http://foldingathome.stanford.edu is all buggered up with regards to their counts.