On Fri, 9 Apr 1999, Chris Antos wrote:
> > 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...?
i am not blasting palm for having this restriction.. it does not
bother me :))
> > 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?
i wont own my PalmIII in 2001..
why would i care?
precations need to be thought of at least, especially from
a database point of view. at some stage (if Palm stays
aroudn long enough) - the hardware will change.
this will require that the databases also be updated.
cheers.
az.
--
Aaron Ardiri
Lecturer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 352 8192 A/H: +46 26 10 16 11
