On 10 Oct 97 19:45:00, Scott was going on about "Year 2000"...
 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?
Interpretation is not compliance. Compliance means there is not a single
doubt as to what 01/14/00 means.
 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?
The separator character has nothing to do with compliance.  You have an
interesting point though.  In new applications, I allow the user to pick
his own separator character via a config file.
 SD> As long as date handling is internally consistent and an intuitive way
 SD> to do things, who cares what the rest of the industry does?
Not to insult you, but I think that's a pretty narrow-minded view.
 SD> I agree that "01/03/103" is awkward and unintuitive, but I fail to see
 SD> 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.
But that's the problem.  In some cases a 2-digit year is ambiguous and
in others it's not.  So why not strive for consistency and unambiguouty
in *all* cases?
 SD> Obviously, for birthdates, a four-digit year is the way to go. On the
 SD> other hand, do you think there is really any point in cluttering up
 SD> the file area listings or the current date display with four-digit
 SD> dates?
I agree that in some cases you may want to save a few bytes due to
screen size limitations. For the rest, use 4 digits for the year. Disks
are cheap these days. Take the following log extract for example
  + 12 Oct 11:03:01 MAX  Begin, v3.01 (task=1)
  : 12 Oct 11:03:01 MAX  Caller at 33600 bps
  + 12 Oct 11:03:10 MAX  Chris Flynn calling
  # 12 Oct 11:03:12 MAX  Given 61 min.
  : 12 Oct 11:03:31 MAX  Browsing msg areas
  # 12 Oct 11:03:57 MAX  Killed #79, area LOC
  + 12 Oct 11:05:02 MAX  Chris Flynn off-line. Calls=2, Len=1, Today=1
  : 12 Oct 11:05:02 MAX  End, v3.01 (5)
Why not use something like this:
  + 12Oct1997 11:03:01 MAX Begin, v3.01 (task=1)
  : 12Oct1997 11:03:01 MAX Caller at 33600 bps
  + 12Oct1997 11:03:10 MAX Chris Flynn calling
  # 12Oct1997 11:03:12 MAX Given 61 min.
  : 12Oct1997 11:03:31 MAX Browsing msg areas
  # 12Oct1997 11:03:57 MAX Killed #79, area LOC
  + 12Oct1997 11:05:02 MAX Chris Flynn off-line. Calls=2, Len=1, Today=1
  : 12Oct1997 11:05:02 MAX End, v3.01 (5)
Or:
  + 19971012 110301 MAX Begin, v3.01 (task=1)
  : 19971012 110301 MAX Caller at 33600 bps
  + 19971012 110310 MAX Chris Flynn calling
  # 19971012 110312 MAX Given 61 min.
  : 19971012 110331 MAX Browsing msg areas
  # 19971012 110357 MAX Killed #79, area LOC
  + 19971012 110502 MAX Chris Flynn off-line. Calls=2, Len=1, Today=1
  : 19971012 110502 MAX End, v3.01 (5)
Similar techniques could be used for screen displays, and everyone will
know *exactly* what date we're talking about.
My aim is to provide positive criticism and encouragement.  I hope it is
taken that way.
Gerry Danen (gdanen@accessweb.com) C+Net BBS @ 403-477-9545
            http://www.geocities.com/SiliconValley/Way/9823
2 years, 80 days, 9 hours, 28 minutes, and 24 seconds until January 1, 2000.
--- Maximus 3.01
 # Origin: C+Net BBS. Programming & Networking. (111:1403/2)
---------------