Re: [HACKERS] postgres and year 2000 - Mailing list pgsql-hackers

From Tom Ivar Helbekkmo
Subject Re: [HACKERS] postgres and year 2000
Date
Msg-id 86zp7op8pk.fsf@athene.nhh.no
Whole thread Raw
In response to Re: [HACKERS] postgres and year 2000  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] postgres and year 2000  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> I agree with Tom Lockhart on this one.

So do I, actually.  However:

> > 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.

Not compile-time, no.  But I think it would be a good thing to have
several run-time options (of which PostgreSQL already has a few), to
specify exactly which behavior is wanted.  For two digit years, it
might be useful to be able to specify to the backend that they should
be handled as, say, 1920-2019, or as the chronologically nearest year
that ends in the two given digits, or maybe even as being in the
current century.  When using a four digit year mode, though, I think
it's a good idea to handle '99' as the year 99, and not e.g. 1999.  It
may be that even this should be an option, and the dangerous mixture,
where there are two years between between the starts of year '99' and
year '2001', should be available on front-end application request.

I would suggest that the defaults be safe, though, probably ISO 8601.

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] lock deadlocks
Next
From: "D'Arcy" "J.M." Cain
Date:
Subject: SUM() and GROUP BY