Billennium's Over - Anything Break? 265
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?
really small stuff (Score:5, Interesting)
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 (Score:4, Informative)
See what happens when you don't use leading zeros? *grin*
Re:really small stuff (Score:2, Informative)
See what happens when you don't use leading zeros? *grin*
So you'd recommend using 000000000000000000000000000000000000access_log.tx
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 (Score:3, Funny)
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
Re:really small stuff (Score:2, Informative)
"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?
Yes, but... (Score:2)
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...
Re:really small stuff (Score:2)
Re:really small stuff (Score:1, Insightful)
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
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 (Score:1)
Re:really small stuff (Score:1)
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 (Score:1)
2001-09-10T18:36:40
Re:really small stuff (Score:2, Insightful)
>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.
Oh? (Score:2)
1000foo
999bar
dwon@zed:~$ echo -e '1000foo\n999bar' | sort -n
999bar
1000foo
Oh yeah... (Score:5, Funny)
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... (Score:4, Informative)
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
Databases item types and sin (Score:2)
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)
Re:Oh yeah... (Score:2)
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 :-)
yes... i broke... (Score:1, Offtopic)
Squid access.log (Score:1)
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 (Score:4, Informative)
broken CVSup on FreeBSD (Score:5, Informative)
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 (Score:2, Funny)
Well, stuff NEARLY broke (Score:1)
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? (Score:4, Insightful)
Re:Anything Break? (Score:1)
Re:Anything Break? (Score:4, Interesting)
Re:Anything Break? (Score:2, Interesting)
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? (Score:2)
Re:Anything Break? (Score:1)
Re:Anything Break? (Score:2)
And what about embedded systems? Many of them still use 8 bit microprocessors.
Re:Anything Break? (Score:2)
But some of them do...
Re:Anything Break? (Score:1)
Re:Anything Break? (Score:2, Funny)
Re:Anything Break? (Score:1)
unsigned integers go twice as far (somewhere around 2106)
Jeroen
Re:Anything Break? (Score:5, Informative)
Nope, there are some more dates with problems prior to 2038, see this list [uic.edu] 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? (Score:1)
That must mean they're all just making this up
Re:Anything Break? (Score:3, Informative)
There's a really extensive one at http://www.merlyn.demon.co.uk/critdate.htm [demon.co.uk], by J R Stockton.
Re:Anything Break? (Score:4, Informative)
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? (Score:2, Informative)
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? (Score:2)
The previous text was a special presentation by a sarcastic asshole.
Actually 4Gigaseconds is the largest for 32bit (Score:2, Informative)
A possible connection? (Score:3, Funny)
Re:A possible connection? (Score:1)
read story here [theage.com.au]
An entire HD (Score:5, Funny)
knode (Score:4, Informative)
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 (Score:2)
-1 troll
IkonBoards are down (Score:1)
CVSup got bit by the 1 billion seconds epoch bug (Score:3, Informative)
http://people.freebsd.org/~jdp/s1g/
BTW, (Score:2, Informative)
My mail client - pronto broke. (Score:2, Informative)
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. (Score:1, Offtopic)
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. (Score:2, Informative)
$a <=> $b
$a cmp $b
$i lt $j
$i < $j
... if someone uses the wrong test they've no one but themselves to blame.
Re:My mail client - pronto broke. (Score:5, Insightful)
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. (Score:5, Informative)
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. (Score:2)
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. (Score:2)
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. (Score:2)
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. (Score:2)
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. (Score:2)
$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. (Score:1)
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. (Score:2)
Re:My mail client - pronto broke. (Score:2)
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. (Score:3, Informative)
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!!
Canon S10 (Score:3, Informative)
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
The cause could be 1) The software in the camera that stores the dates in the images or 2) the photo viewing software itself. or 3) Something totally different. (Windows ?)
OpenLDAP slave servers completely broken (Score:5, Informative)
OpenLDAP [openldap.org] 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 [openldap.org].
The problem is detailed in the openldap-bugs mailing list [openldap.org] -- 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!
Bah, I can't figure the new slashdot out (Score:2)
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. :-(
Funny buisness (Score:1)
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.. (Score:1)
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
As a matter of fact... (Score:2)
I thought I missed a party there... (Score:1)
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... (Score:2, Interesting)
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.
Well, it *nearly* broke... (Score:2)
Does that count? *grin*
Anything Break? DID YOU NOT NOTICE? (Score:5, Funny)
Well anyway, I declare myself God until further notice.
Re:Anything Break? DID YOU NOT NOTICE? (Score:4, Funny)
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? (Score:2)
[bows head]
cvsup broke (Score:4, Redundant)
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 (Score:3, Informative)
% ls -tr | tail
999878615.18243.pop.xxx.com:2,S*
999882709.76833.pop.xxx.com:2,RS*
999883989.13343.pop.xxx.com:2,S*
999900385.97510.pop.xxx.com:2,S*
999906796.21947.pop.xxx.com:2,S*
999914926.66179.pop.xxx.com:2,S*
999922220.49590.pop.xxx.com:2,S*
999975475.10798.pop.xxx.com:2,S*
1000040737.72591.pop.xxx.com:2,S*
1000062814.85554.pop.xxx.com:2,*
I think it was an old version of uw-imapd with maildir patches.
I wrote a short script to rename all files created before 1,000,000,000 with a leading zero. The resulting file names with "09*" fixed the problem!
-Dave
Notice about seconds overroll (Score:5, Informative)
I would like to make your attention on bug which was introduced tonight and can affect some people who are using (var)char field to store timestamp data.
It is not worst security bug. It affects only people who already had bug in their code. Just now this bug become visible/exploitable.
This is not MySQL bug. This is how people use their database. Also similar situation can be found in other software. I would like to inform people in public list as maybe some people have to search similar problems.
The problem: Computers store time and date usually as integer value representing amount of seconds from 1 January 1970. Tonight it overrolled from 999999999 to 1000000000.
Possible bug and exploit relies on fact that some people have used character type of field to store this seconds information (we have already such case)
example:
mysql> create table session (expire varchar(100) not null);
Query OK, 0 rows affected (0.31 sec)
mysql> insert into session values (999999997), (999999998), (999999999),
(1000000000), (1000000001);
Query OK, 5 rows affected (0.00 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql>
mysql> select * from session;
+------------+
| expire |
+------------+
| 999999997 |
| 999999998 |
| 999999999 |
| 1000000000 |
| 1000000001 |
+------------+
5 rows in set (0.00 sec)
mysql>
Let's assume that this table contains values we use somewhere to authenticate users. After user logs in, we write down session expiry time and later we check it like this:
mysql> select count(*) from session where expire >= '1000032535';
+----------+
| count(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
mysql>
WOW, what happened? Shouldn't be 100003253 bigger than any value in table? It worked yesterday!
In MySQL we suggested people to use quotation marks around integer values. This can avoid many web-based attacks targeted to modify SQL commands (more information on http://www.mysql.com/doc/G/e/General_security.html ). This is the reason why people put quotation marks around integer expressions and this is correct. Also automatic type casting will fix the source problem is column data is integer or some time/date vale. But when both column is character type and expression, they get compared as strings. And as we know, strings get sorted in order:
1,11,2,22
but integers:
1.2.11.22
So, this is why 100003253
It is possible that some web applicatons have endless expiry times now and not only in MySQL contexts.
Tonight I'm gonna party... (Score:5, Funny)
(Shamelesly ripped from ntk.net).
Nothing Broke -- Damn (Score:2, Funny)
Then again, I could do without the Vietnam War Redux. Oh well.
In Summary... (Score:2)
Use the Date format that your database has, as it should be able to do much better comparisons with dates in SQL, instead of seconds stored as text.
Did I miss anything?
Veritas Netbackup (Score:3, Informative)
pine / UW IMAP (Score:4, Informative)
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 (Score:2)
#!/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 =~
$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";
}
}
NUTS breaks (Score:2)
A bit easier-to-understand explination. (Score:3, Informative)
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. (Score:2)
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. (Score:2)
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.
Java dates (Score:2)
Java does have dynamic int classes like BigInteger, but I think they would be too inefficient for something with such widespread use as dates.
Re:A bit easier-to-understand explination. (Score:3, Informative)
There are so many errors in this that I find it very worrying that it ever got a score of 4.
Re:A bit easier-to-understand explination. (Score:2)
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.
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.
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.))
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.
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. (Score:2)
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 explanation. (Score:2)
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 explination. (Score:2)
No problems here... (Score:3, Insightful)
my propane grill... (Score:2, Funny)
billenium non-bug (Score:2, Informative)
My employer got bitten (Score:2, Interesting)
Apparently, this version of the library could not perform the "epoch" for seconds beyond the billenium and would report a year 1000 years too early! Of course, this bug was fixed in 1.34 and in fact the current version of Date::Manip is 1.40. Unfortunately, this company doesn't update as often as it should since upgrades can break backward compatibility and need extensive testing. But there you have it, a top company got bitten!
Damn, I missed it. (Score:2)
My stomach! (Score:2)