> > "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> > > We do need to handle two-digit years, [...]
> > Is it at all possible to get away with _not_ doing so? It is, after
> > all, incredibly stupid to use two-digit years in anything but spoken
> > conversation, so in a way, I'd prefer computer systems to blankly
> > refuse them. If they're allowed at all, I'd say parse them so that
> > a year specification of '99' means the actual year 99. _Not_ 1999.
> Falling back to a Unix standard...type 'cal 99' and see which year you
> get :)
> I agree with Tom on this...if someone types a year of 99, we should
> presume that whomever entered it knew what they were entering, and/or
> that the programmer of the interface had enough sense to program
> checks into it...
Well, we're all Toms here, but I'll assume you are trying to agree with
Tom H.
You may think that ISO-8601 is the way to go, and I may think that
ISO-8601 is the way to go, but it isn't yet a universal usage, so why
should we presume that it is? That timezone stuff is pretty annoying and
confusing too, so perhaps we should revert Postgres back to its pre-v3
GMT-only date support? :)
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.
istm that it is *much* easier to write an app which restricts data entry
to a particular style, which is then forwarded to our backend, than to
accept *only* a particular style in the backend and expect every client
app, in every supported language, on every platform, to learn how to
accept general date values and then convert them to a single specific
one.
I should also point out that in a recent review of our database the
date/time I/O was mentioned (with 2 or 3 other features) as being
particularly noteworthy. So *someone* thought it was a nice feature :)
I suppose we could consider a compile-time or run-time option to
constrain dates to a single style. Seems a bit of overkill, and
personally I'd like to work on outer joins, but...
- Tom
