Re: Timestamp Summary

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(dot)Grittner(at)wicourts(dot)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
>
>