Scott Dudley wrote in a message to Gerry Danen:
 GM>> max is y2k compatible. for dates, using "100" as the year means
 GM>> "2000".. "143" = "2043"
 GD> That's not compliance, that's a work-around. Compliance means 4-digit
 GD> years and not some interpretation by the software.
SD> Why does compliance mean 4-digit years?  If Maximus were to support
SD> 2-digit years properly ("01/14/00 = January 14, 2000"), how on earth
SD> could that not be compliance?
SD> Furthermore, suppose that Maximus does use four-digit years, but
SD> assume that it uses dashes instead of slashes to separate the
SD> components.  I suppose that this would make it "incompliant" too?
 I use a date format of YY.MM.DD on my system -example 97.10.12
 I guess THAT would not be compliant either, since it's not 10/12/97
 like every other North American.
 And what of those who prefer 12-10-97?  Non-compliant?
 Bull feathers!
SD> As long as date handling is internally consistent and an intuitive
SD> way to do things, who cares what the rest of the industry does?
 People who want everything done /their/ way, of course.  Nah, I think
 I'll stick to YY.MM.DD.
 Works for me!
SD> I agree that "01/03/103" is awkward and unintuitive, but I fail to
SD> see why we *must* replace it with four-digit years in cases when a
SD> properly-interpreted two-digit year is unambiguous and works just as
SD> well.
 Or as badly.  Year 00 is just going to look weird, as if someone
 forgot to fill in the date.
SD> Obviously, for birthdates, a four-digit year is the way to go.  On
SD> the other hand, do you think there is really any point in cluttering
SD> up the file area listings or the current date display with
SD> four-digit dates?
 Please don't!  The screen is only so wide!
 Patrick
--- timEd 1.10
---------------