You are referring to this problem I think..
$ perl -e 'print scalar localtime time*3;'
Thu Sep 28 21:26:38 1933 Ouch!
There are some interesting pages at:
The last link has specific advice for your case:
"What can be done?"
There are two approaches to fixing this problem. The first is to not use 'time' and its companion functions. Instead, use more modern function calls which will not have this rollover problem for millenniums to come. The second approach is to develop your own version of 'time' which returns a data type with greater capacity. This means that you will also have to rewrite the companion functions. Additionally, you will have to check your code to make sure that it does not assume a certain data type. 'time' is defined such that it returns a data type of 'time_t' . You can redefine 'time_t' to a larger capacity data type.
Hopefully, compilers will address this issue within the next 10-20 years. In that case, you will not need to rewrite the 'time' functions. However, at the very least you will need to recompile all of your old applications. More likely, you will have to examine all of your code to make sure that your developers did not cast the 'time_t' data into a basic (or integral) data type such as an int or long int. You will probably find at least one instance of this in every large project. And one instance of this bug is enough to stop your software in its tracks.
We would not recommend that you spend a great amount of money eliminating this software problem in your existing software. However, you would be advised to at least distance yourself from 'time' and its companion functions in current and future development efforts. Using an object-oriented approach, you can still make use of these functions without risking a Y2K type phenomenon. Better yet, you can begin to use API's that are a bit more far-sighted. At MPC we have already put this into practice in our software development efforts.
But the above rollover will only happen if you are using the same perl on the same machine/OS/BIOS, I think. The source code of your program would not have to change if it is interpreted by a (yet to be created?) more modern version of perl.
That said, it would be nice if we had a way to explain perl modules to programs with an aim to automated software integration.
Some keywords- "web annotation","syntactic web", "natural language processing" will probably be full grown by then (see some in google directory). But that seems to be in early stages, we could use something perlish or corbaish even now. So I think your question is very relevant to us now too.
Even with today's technology we should be able to describe characteristics of our programs in a way that a machine can understand. Also, there is currently no standardized way of describing Y2.038K problems. Ultimately things like failure modes of 2038-challenged unix software and embedded systems can be described with some kind of interface description language - maybe perl is good for this (Consider perl Makefile.PL as a forerunner). That way we can hope that when nearly every piece of hardware in existence today crashes and burns, the important things can be virtualized on 64+ bit machines that scan these descriptions of dead systems and rescue us. Doesn't seem like science fiction to me.. Anyway I would like to see something more parseable in manpages and whatnot, perldocs could gain another section for machine-readable descriptions too.
Anyway to directly answer your question (how to annotate your program) maybe it would be useful to put tags in comments to indicate dangerous lines, and provide a separate file which describes the problems. You could also try describing exactly what is dangerous about it in simplified english inside <Y2.038K> </Y2.038K> tags, it might just work!
In reply to Re: 2038 bug
in thread 2038 bug
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||