TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Year 2000 From:"Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM> Date:Fri, 9 Dec 1994 08:39:29 -0600
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