I saw that one coming earlier today while working on a perl script. Had occasion to call Unix time while resolving a bug. But sorry I didn't alert you.
But the point is, none of us be alive when Unix time reaches 9876543210.
If anyone's interested, here's how to get an RFC-822 compliant date from Unix Time (required for RSS feeds) in Perl.
# Gets the current time in RFC822 format
sub rfc822 {
use POSIX qw(strftime);
# Alternate module below
# use Date::Format;
my @BuildDate = localtime(time);
$BuildDate = strftime("%a, %d %b %Y %H:%M:%S %z", @BuildDate);
}
Now that would really be impressive if anyone used Perl anymore. It's much easier in PHP since 'strftime' is a built-in function.
But the point is, none of us be alive when Unix time reaches 9876543210.
it can't do that! :) The problem with a 32-bit integer like this is that it can only count 4,294,967,296 seconds, or 136 years. This covers a period between 1901 and 2038.!!! :D
doesn't count leap years either, technically, it would end 34.25 days earlier then if we didn't use leapyears! Eek!
You are right.
I researched this a bit, and signed Unix time_t, which you are referring to, has already been ported to 64 bit on several servers and OS.
Same for POSIX Unix time, which starts at the 1-1-70 epoch, and would take us to the year 2106 on 32 bit.
Either way, I bet they have it sorted before 2038, when I won't have to worry about it. I read that 64 bit could run for 300,000 years.