Re: Timestamp Summary

On re-reading Christian's email, I see that he is only proposing to
change the JVM's time zone once, not once per connection.  Still, having
a JDBC driver tinkering with JVM configurations like this is just not an
option for me.  If we fix the other problems, he could do what he wants
by changing to a non-DST time zone in the enclosing application.

-Kevin


>>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> 07/25/05 12:13 PM >>>
As someone who is interested in timestamp columns only to hold actual
moments in time, I'm very uncomfortable with Christian's proposed "fix".
 We have a highly multithreaded environment dealing with multiple
database servers.  Having various threads all setting the default
timezone for the JVM to something inaccurate based on connections to a
variety of servers seems likely to break much more than it fixes.  The
primary "problem" being solved by this technique is that it is hard to
record a timestamp representing a moment which doesn't exist any more
than do the following:

2005-02-29 00:00:00.0
2005-10-35 00:00:00.0
2005-10-25 00:75:00.0

It is fine with me if moments that don't exist can't be stored in the
database.  Others have pointed out problems with storage and retrieval
of valid Timestamp objects.  Those seem to me to be the problems to
address.  I think that would go part of the way toward addressing
Christian's problems; but, since you can't actually create a Timestamp
object within a JVM set to the correct time zone to represent what he
wants, his particular issue will always require munging the Java runtime
environment, which is simply not an option in many situations.

-Kevin




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq