> It is nice to provide smart date interpretation in the backend but in
> order to be really Y2K compliant we *MUST* forbid any ambiguous date
> format in the backend. If the user insists in wanting two-digits years
> in his interface he will write his own not-Y2K-compliant conversion
> code.
I've never heard that interpretation of Y2K compliance. Remember that
once a date has been interpreted, it is *never* ambiguous since it is
stored as a full value. The rules for interpretation are not ambiguous,
and follow common usage.
The cases you found which did not "do the right thing" allowed me to fix
bugs, but imho did not illustrate fundamental problems in dealing with
date/time. The *only* bothersome case really is that for a Roman from
the year 88 sitting down in front of Postgres, entering dates, and upon
seeing "1988" in a result saying: "What the ...?".
Saaayyyyy, you're not one of those research types bringing old bodies
back to life are you? I've seen movies about that... ;)
But back to the Roman, the modern calendar wasn't adopted until the 17th
or 18th century, so he'd be confused anyway.
Regards.
- Tom ;)