Re: Timestamp Summary - Mailing list pgsql-jdbc

It's somewhat easier to track the servers timezone, as opposed to
setting it
The server will issue a notice and the new timezone when/if it is
changed

I've tried hacking that in, but I think there is some weirdness in
the driver where
we convert back and forth. I'd ideally like to use joda-time for the
conversion, however
I'm not sure including someone else's library is a good thing.

Dave
On 25-Jul-05, at 1:27 PM, Kevin Grittner wrote:

> 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
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>
>