From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | The Hermit Hacker <scrappy(at)hub(dot)org> |
Cc: | Tom Ivar Helbekkmo <tih(at)nhh(dot)no>, PostgreSQL Hackers <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] postgres and year 2000 |
Date: | 1999-01-12 02:48:23 |
Message-ID: | 369AB7F7.A38D6C10@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > "Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas G. Lockhart | 1999-01-12 03:05:16 | Re: [HACKERS] JOIN syntax. Examples? |
Previous Message | Hiroshi Inoue | 1999-01-12 00:40:22 | RE: [HACKERS] MVCC works in serialized mode! |