🚀 go-pugleaf

In article <6882@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes:
>In article <3156@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes:
>
>>The asctime function for converting date and time to the ASCII string
>>equivalent seems to fail for years after 2038.  (This should tell
>>you what sort of error checking our quality assurance team does,
>>and how long we expect our product to be in the field).
>
>Well, how many computer programs written in 1942 (or earlier) are still in
>use? How many computers built before 1942 are still in use? Do you *really*
>expect your product to still be in use 48 years from now?

Better question: how many of those older programs manipulated future dates?
Just because the software was written in 1989 doesn't mean that it won't
manipulate dates past the year 2038.

>>Is this a known bug of asctime?  Does Microsoft intend to fix this
>>one anytime soon?

It is a known limitation of asctime().

>If they are still in business, they *may* fix it in 2037.

You are truly an optimist.  I'd bet on them announcing asctime/2 in 2039,
but it won't be available until 2041, and you have to upgrade your machine
to run it @;-)

But seriously, folks -- There are a lot of programs that only use 2 digits
to store the year in a date (data processing and accounting packages).
A significant percentage of the world's computer installations will be
brought to their knees when accounts payable programs all over the world
can no longer project how long payment can be delayed while maintaining
early-bird discounts and accounts receivable programs determine that all
payments are nearly a century overdue.  I sure hope the guys who write
programs for the stock market have better foresight...

(Of course, we will all be rich and busy in our new consulting businesses
then, and a new buzzword achronym will be invented to describe software
that can survive the turn of the century.)