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

From Massimo Dal Zotto
Subject Re: [HACKERS] postgres and year 2000
Date
Msg-id 199901130923.KAA00836@nikita.wizard.net
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
List pgsql-hackers
> 
> "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

It is nice to provide smart date interpretation in the backend but in
order to be really Y2K compliant we *MUST* forbid any ambiguous date
format in the backend. If the user insists in wanting two-digits years
in his interface he will write his own not-Y2K-compliant conversion code.

Someone mentioned the ISO-8601 standard. Could you post a summary of
this standard ?

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] CONSTRAINTS...
Next
From: Tom Ivar Helbekkmo
Date:
Subject: Re: [HACKERS] postgres and year 2000