Re: [HACKERS] postgres and year 2000
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] postgres and year 2000 |
Дата | |
Msg-id | 16159.916151591@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] postgres and year 2000 ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Ответы |
Re: [HACKERS] postgres and year 2000
|
Список | 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
В списке pgsql-hackers по дате отправления: