"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> If we don't accept a reasonably wide range of common date and time
> specifications, then each app will have to, or may have to, do that.
Just to throw another Tom's opinion into the mix ;-) ...
I agree with Tom Lockhart on this one. If we don't provide date
interpretation in the backend, that doesn't make the problem go away.
It just means that every frontend application has to re-invent that
same wheel. And, no doubt, cope with bugs in their re-invention.
Getting it right *once* is the whole idea of re-using software --- else
why not expect everyone to write their own whole DBMS?
A frontend programmer who has his own strong ideas about how to
interpret dates is certainly free to do so, and then to pass his results
to the backend in some unambiguous format like ISO. But not many people
will really want to do that --- they'd much rather have a flexible and
robust solution provided for them.
Date handling is inherently messy because there are so many different
conventions. But we can't make that go away by decree. Guess what:
people will keep writing two-digit years, even after the turn of the
century, and will expect their computers to understand what's meant.
> I suppose we could consider a compile-time or run-time option to
> constrain dates to a single style.
I see no need to do that. A particular frontend programmer who wants
that behavior can make it happen himself --- should you break other
apps that may be talking to the same database server in order to do
it for him?
regards, tom lane