Re: Year 2000

[Laurie Rubin <lmr -at- SYL -dot- NJ -dot- NEC -dot- COM>]

I recently had to remind my designer of just this problem, that he had to
change a two-digit year field to four to allow and expect only 4 digits.
With only a few years to go, it is important that we make designers start
doing this, now!

> This message was triggered by:

> ********************************
> I just had to edit a technical paper and saw a date expressed
> as 08/17/00; implying the year 2000.

> Question is, is this going to be the commonly used form of
> expressing the year?
> ********************************

> For those of you in big-iron, corporate computing environments, this is
> *extremely* serious business.  My boss just circulated an article (which,
> naturally, I can't locate) explaining that this change will create havoc
> when it hits, and very, very few shops are addressing the issue.

> The reason?  Create a list of dates, including dates from this century and
> the next, written in the last-two digits style; then try sorting that list
> of dates by year. Notice where the dates from the next century fall.  Now,
> try doing some subtraction.  (Say, 1995 from 2004, or rather: 95 from 04.)

> Now, imagine, say, your customer credit program doing the same thing.  Are
> you breathing hard yet?  If not, imagine all the date-dependent
> transactions going on in millions of lines of that crusty old COBOL code
> running on the beast in the basement, and imagine the costs and time
> involved in tracking down, rewriting and testing them all. OK, go take an
> asprin.

> The consultant who wrote the article said most IS managers are just not
> addressing the issue.  Like most system issues, this is expensive, unsexy,
> tedious, adds no new value, expensive, boring, and expensive.  IS managers
> do not want to go ask for several million dollars in contract programming
> time just to keep the lights on; the consultant said many of them don't
> expect to be in their position when things blow up, so they just aren't
> dealing with the problem.

> So, there's an opportunity here for technical communicators.  Ever used to
> being the bearer of bad news, ("We tested it with the users and they
> laughed.") be the first in your development group to ask the question.  If
> naught else, throw in some next-century dates the next time you're at a
> usability test and see what happens.  If your system rolls over an plays
> dead, you may want to point that out.

> Skoal,

> Doug                            "Women are designed for long,
> ENGSTROMDD -at- phibred -dot- com           miserable lives, whereas men are
>                                  designed for short, violent ones."
>                                   - Estelle Ramey

> usability test and see what happens.  I