From: Michael S. Lorrey (mike@datamann.com)
Date: Mon Apr 10 2000 - 10:26:24 MDT
"M. E. Smith" wrote:
> Over several weeks ago, someone on this list made
> comments to the effect that the "Y2K Problem" was a
> unique event never to be repeated. The reasoning was
> that, since storage space is now plentiful and
> databases routinely are able to store dates in formats
> that support the far, far, far future (I can't
> remember the details, but we were talking an
> "astronomical" number of years from now), there will
> never again be a calendar event that threatens to
> break a significant fraction of computer programs.
>
> I believe an implication of the post I refer to was
> that there will be no "Y10K" problem, for example.
>
> Since then, I have been sensitive to code which is an
> exception to this. That is, every time I see code that
> would fail in Y10K, I notice it.
>
> And I have noticed code like this an awful lot. For
> example, in Web development, it is common to pass data
> to servers as parameters at the end of URL's. When
> passing dates in URL's, the habit I see is to use a
> four-digit year. When I suggest that a five-digit year
> be used ("just for grins", I say), people just roll
> their eyes at me. (People do that a lot.)
>
> Eight thousand years is a long time to fix these
> things, and it seems unlikely that there will even be
> URL's as we now know them in 9999 C.E., so I realize
> this is a mainly nitpicking, but it is NOT the case
> that just because we have plenty of storage space and
> super-duper date fields in databases, there will
> therefore be nothing like Y10K problem. (I say
> "nothing like" because I accept the probability that
> the "Gregorian calendar" will not be used for another
> 8000 years.*) All it requires is "shortsightedness",
> which probably will never go away entirely.
>
> Also, isn't there some kind of limit on the internal
> Unix clock format? I remember hearing somewhere that
> it only goes to something like 2038. If so, that seems
> like a problem, although probably not a big one (I bet
> the OS could be upgraded without having to change
> application code).
>
> -- M. Smith
>
> * Once, after being forced to write code for the
> umpteenth time to determine the number of days in a
> given month, I ALMOST included a joke comment to the
> effect that all months should have 28 days (4 weeks
> exactly) to make programming easier, and TO HELL with
> the phases of the moon and the rotation of the Earth!
> So what if it meant your birthday would be in a
> different season every three years? Don't farmers have
> almanacs? Are there not more programmers now than
> farmers? Do not the needs of the many outweigh the
> needs of the few?
>
> Actually, if there were 13 months of 28 days each,
> that makes 364 days a year. It would take almost a
> century for your birthday to change seasons. Isn't
> that close enough? And the 13th month could be named
> "Smithember", because I thought of it! Yeah! And all
> you people who were born on the 29th, 30th, or 31st
> would just be out of luck, no birthdays for you...
>
> See! You're rolling your eyes!
Well, at least you would be giving plenty of 29 year old women an excuse to
never age....
The extra day and a quarter could be kept as Memory Leakage Day, and would not
belong to a month. Of course, you could make Memory Leakage Day equivalent to
February 10th, since I already own that day (in Lowell, Massachusetts, Feb 10th
is Michael Scott Lorrey Day).
This archive was generated by hypermail 2.1.5 : Fri Nov 01 2002 - 15:27:56 MST