cramer@optilink.UUCP (Clayton Cramer) (02/17/90)
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).
Is this a known bug of asctime? Does Microsoft intend to fix this
one anytime soon?
--
Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer
The government doesn't trust you with a gun; why do you trust them with guns?
===============================================================================
Disclaimer? You must be kidding! No company would hold opinions like mine!toma@tekgvs.LABS.TEK.COM (Tom Almy) (02/18/90)
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? >Is this a known bug of asctime? Does Microsoft intend to fix this >one anytime soon? If they are still in business, they *may* fix it in 2037. (:-) throughout, well mostly throughout.) Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
dold@mitisft.Convergent.COM (Clarence Dold) (02/19/90)
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 #include <limits.h> ttime = LONG_MAX; The current time in Milliseconds: 2147483647 Mon Jan 18 19:14:07 2038 ttime++; Invalid number of milliseconds: -2147483648 Mon Jan 18 19:14:08 2038 -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007
bcw@rti.UUCP (Bruce Wright) (02/19/90)
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? Inasmuch as essentially _no_ commercial computers were built before 1942, this is not a very good analogy. You might consider the number of computers built before 1960 that are still in use, and the amount of software written before 1960 that is still in use. There's quite a bit more than you might think - the Post Office turned off their last 704 machine only in the late 1970's (1978 I think) which would be close to a 25 year lifespan for the machine. There are probably other 704's that continued to run for longer than that, in some Third World country. There is every reason to believe that modern machines are more durable than 704's. On the other hand, the _percentage_ of machines and software that old in 2038 will probably be tiny, but used in places that are relatively immune to change (government, banks, perhaps automating some obsolete factories, or running obsolete aircraft). I can easily see how having something break at that time could be a _major_ inconvenience, since fixing it would presumably be rather hard (all the authors & engineers being long gone). I know that Tom was at least somewhat joking, but for certain classes of problem this is no laughing matter. Bruce C. Wright
dacseg@uts.amdahl.com (Scott E. Garfinkle) (02/21/90)
From article <6882@tekgvs.LABS.TEK.COM>, by toma@tekgvs.LABS.TEK.COM (Tom Almy): > 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). You would have saved a lot of money in your own time and that of your testing team (I presume) if you had paid the $150 (or was it $100) for the library source for their runtimes. If you really want your product to run after year 2038, just fix the problem yourself. I know you paid the money, etc., but presumably you're in business to make money/product, not prod other people's support departments. This is *not* meant in any derogatory fashion, just as a suggestion. I have found the library sources quite useful, personally. -scott e. garfinkle
pipkins@qmsseq.imagen.com (Jeff Pipkins) (02/21/90)
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.)
person@plains.UUCP (Brett G. Person) (03/10/90)
The problem appears to be an int overflow. This would appear to be a limitation of the machine rather than the compiler. Just guessing though. -- Brett G. Person North Dakota State University uunet!plains!person | person@plains.bitnet | person@plains.nodak.edu