I'm all for ISO 8601, but it does not apply in this case. The serial number is not a textual representation of a date, it is a 32-bit unsigned integer in a DNS record that must be increased whenever the record is updated. A "YYYYMMDD" format, aside from resulting in a basically useless integer, would only change once per day. The UNIX timestamp format really does make the most sense here.
Huh? That's not a Ximian Gnome 2 preview, that's Microsoft Bob running in VMWare on KDE 1.1! Did you actually read the article before copying the link that said "screenshot"?
No it's not. There's no limit to the number of moves in a game of chess; you can spend all eternity moving pieces back and forth if you like.
Actually, the 50-move rule allows you to put an upper bound on the number of moves in a game. In particular, there can't be more than 96 pawn moves and 30 captures, and pawn moves/captures can be at most 50 moves apart, meaning that a chess game can't last more than 6350 moves. This could probably be improved somewhat.
Actually, taking a logarithm to the base x is quite different than writing a number in base x. You can take a logarithm base e -- such a logarithm (not the number e itself) is called a natural logarithm -- but you can't write a number in base e. And FYI, e is about 2.718281828459045...
I knew Java was over-engineered, but this is taking things a bit far.:-p (and possibly being a little optimistic on the popularity of Java over the next 292 million years)
It's better to over-engineer than to under-engineer. 2038 isn't too far away; things would be a whole lot nicer if everyone had used 64-bit timestamps. And I don't think anyone's going to miss the extra 4 bytes of storage needed.
Slashdot Mirror
You forgot Fedora.us, which is has more-or-less official addon packages.
I'm all for ISO 8601, but it does not apply in this case. The serial number is not a textual representation of a date, it is a 32-bit unsigned integer in a DNS record that must be increased whenever the record is updated. A "YYYYMMDD" format, aside from resulting in a basically useless integer, would only change once per day. The UNIX timestamp format really does make the most sense here.
Here.
Just curious -- wouldn't Kevin's patch also make Linux run faster in VMWare as well?
Huh? That's not a Ximian Gnome 2 preview, that's Microsoft Bob running in VMWare on KDE 1.1! Did you actually read the article before copying the link that said "screenshot"?
I've been running 8.0 since Wednesday, because there was a mirror site with misconfigured permissions. :-)
It's hidden pretty well, but I found it here: http://www.x10.com/x10ads.htm.
Actually, taking a logarithm to the base x is quite different than writing a number in base x. You can take a logarithm base e -- such a logarithm (not the number e itself) is called a natural logarithm -- but you can't write a number in base e. And FYI, e is about 2.718281828459045...
No, Pi has been proven to be irrational, and in fact transcendental (it is not the root of any finite polynomial with integer coefficients).
Whether or not UNIX will be running before 1970, it still might be useful to store dates before 1970, such as birthdates, etc.
That will probably happen anyway, whether you like it or not! :-)
It's better to over-engineer than to under-engineer. 2038 isn't too far away; things would be a whole lot nicer if everyone had used 64-bit timestamps. And I don't think anyone's going to miss the extra 4 bytes of storage needed.