Re: A creepy story about dates. How to prevent it?

At 6/19/03 9:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>It would make sense to offer a "strict" mode in which the date order
>has to be what DateStyle suggests.  I'm astonished that no one seems
>to get the point that there are also good uses for "lax" parsing.

Hmmmm.... I would strongly disagree that there is any use for this.
Research has shown that good human interface design is (in part) a
product of systems that act consistently, allowing the user to develop a
mental map of how the system works. Allowing "lax" parsing teaches the
user an invalid mental map.

For example, if a user starts working at a company on January 15, and
finds he can successfully enter dates as 2003-15-01 (because the entry
screen confirms the date as "Jan-15-2003"), the user could reasonably
come to the conclusion that YYYY-DD-MM is the "correct" way to enter a
date.

Along comes February 1. The user enters the date as "2003-01-02", but he
has been on the job for two weeks and no longer bothers reading the
confirmation screen: he doesn't notice that it inexplicably shows
"Jan-02-2003". The resulting bogus data stems directly from the system
previously trying to "help" the user by doing what it thought he meant,
instead of what he typed.

Since it is impossible to support odd formats such as YYYY-DD-MM and
interpret input in a consistent manner, PostgreSQL should not allow it.
"Do what I mean instead of what I typed" data interpretation is already
dodgy; "Do what I mean instead of what I typed, but only from January 13
through January 31, and not from February 1 to February 12" seems
obviously flawed.

--
Robert L Mathews, Tiger Technologies