> true.. but are we not talking about dates that will occur
> after 2031? dont you think by then we will be able to have
> more memory on board?
yes. and don't you think by then they'll have a new version of the OS that
supports 2031 and later...?
> there are trade-offs.. smaller is better.. but smaller means
> more chance of problems later.. do you care about those
> problems? i do.
let's be real. there's a big difference between a mainframe that doesn't
handle a wide date range, and a handheld organizer that doesn't handle a
wide date range.
> of course programmers wanted to have 4 digits.. but what else
> can they do? the management pays their wages.. we just have
> to sit back and do it their way.. and then they give us
> hassle when the 'shit hits the fan'.
i think you're empathizing with a hypothetical scenario, there.
> we know 'why' and 'why not'.. maybe as designers right now,
> we should spend the extra time to consider what needs to
> be done in 2031.
maybe it HAS been considered. and maybe it's been postponed reasonably. i
don't care right now if my handheld organizer will continue to work in 2031.
it cost me less than $500 and i'll probably break it long before then. it
has different constraints than the big mainframe that i paid $1,000,000 for
and handles our corporate accounting etc.
the Y2K problem is not due so much to the fact that software was designed
poorly, as it is to the fact that people waited too long to care about it
and get new versions.
life-critical hardware is another story. for instance, if i am stupid
enough to design a pacemaker that keeps track of the current date and
actually uses the current date in its internal calculations, then i should
have been at least smart enough to use a chip that will handles dates at
least as far into the future as the maximum known total lifespan of a human.
but i shouldn't be tying life-critical things to unimportant data such as
the current date.
> maybe when you write your little program that uses the
> DateType as a storage mechanism - you should also write
> a program that can store it in a less-efficient way.. or
> at least a conversion program that can be used in 2031.
there really is such a thing as trying to jump on something too early.
> design is being prepared for everything.
that's a nice-sounding catch-phrase. but "everything" is a subjective term.
for instance, i'm fairly confident that when you say "everything" you are
excluding such possibilities as a global shift to metric time, or Swatch
Internet time, or takeover by an alien power that forces us to change our
clocks to count backwards, etc. you have some idea in your head about what
you consider to be reasonable things to prepare for. another example -- do
you think we need to design for the year 3000 right now?
