Thread

1. Re: [HACKERS] postgres and year 2000

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-01-12T14:33:11Z

   "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
   
   

2. Re: [HACKERS] postgres and year 2000

   Tom Ivar Helbekkmo <tih@nhh.no> — 1999-01-12T19:55:19Z

   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"
   
   

3. Re: [HACKERS] postgres and year 2000

   Massimo Dal Zotto <dz@cs.unitn.it> — 1999-01-13T09:23:00Z

   > 
   > "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  |
   +----------------------------------------------------------------------+
   
   

4. Re: [HACKERS] postgres and year 2000

   Tom Ivar Helbekkmo <tih@nhh.no> — 1999-01-13T13:04:41Z

   Massimo Dal Zotto <dz@cs.unitn.it> writes:
   
   > Someone mentioned the ISO-8601 standard. Could you post a summary of
   > this standard ?
   
   Very quick summary: Today is '1998-01-13', and I'm posting this at
   approximately '1998-01-13 13:02:00Z' (the Z is for Zulu, which is the
   military designation for UT), or '1998-01-13 14:02:00' my local time.
   
   See http://www.iso.ch/markete/moreend.htm for more information, and a
   downloadable PDF version of the complete standard.
   
   -tih
   -- 
   Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"
   
   

5. Re: [HACKERS] postgres and year 2000

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-01-13T15:24:11Z

   > 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.
   
   I've never heard that interpretation of Y2K compliance. Remember that
   once a date has been interpreted, it is *never* ambiguous since it is
   stored as a full value. The rules for interpretation are not ambiguous,
   and follow common usage. 
   
   The cases you found which did not "do the right thing" allowed me to fix
   bugs, but imho did not illustrate fundamental problems in dealing with
   date/time. The *only* bothersome case really is that for a Roman from
   the year 88 sitting down in front of Postgres, entering dates, and upon
   seeing "1988" in a result saying: "What the ...?".
   
   Saaayyyyy, you're not one of those research types bringing old bodies
   back to life are you? I've seen movies about that... ;)
   
   But back to the Roman, the modern calendar wasn't adopted until the 17th
   or 18th century, so he'd be confused anyway.
   
   Regards.
   
                       - Tom ;)
   
   

6. CVS Branch Retrieval?

   Clark C . Evans <clark.evans@manhattanproject.com> — 1999-01-13T16:15:26Z

   The FAQ_CVS does not discuss how to retrieve 
   and follow particular branches.  Could someone
   give me a quick lesson, (or better yet, update the FAQ?)
   
   I need to be able to fetch and build the current
   production release.  Right now I'm fetching
   and building 6.5
   
   :) Clark
   
   

7. Re: [HACKERS] CVS Branch Retrieval?

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-01-13T17:04:13Z

   > The FAQ_CVS does not discuss how to retrieve
   > and follow particular branches.  Could someone
   > give me a quick lesson, (or better yet, update the FAQ?)
   
   Don't put any new work into the FAQ! I've merged it into cvs.sgml, but
   have not finished marking up cvs.sgml (there was some other stuff to
   merge in, and...).
   
   > I need to be able to fetch and build the current
   > production release.  Right now I'm fetching
   > and building 6.5
   
   Look at doc/src/sgml/cvs.sgml, which aside from the tags has some words
   (taken from one of scrappy's e-mails on the subject, maybe not on one of
   main lists) on how to retrieve tagged versions.
   
                         - Tom