Re: [HACKERS] postgres and year 2000
От | Massimo Dal Zotto |
---|---|
Тема | Re: [HACKERS] postgres and year 2000 |
Дата | |
Msg-id | 199901130923.KAA00836@nikita.wizard.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] postgres and year 2000 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] postgres and year 2000
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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 по дате отправления: