Re: Timestamps without time zone

Στις Friday 11 January 2008 07:12:24 ο/η Kris Jurka έγραψε:
>
> On Thu, 10 Jan 2008, Achilleas Mantzios wrote:
>
> > I tried other apps with the new postgresql-8.2-507.jdbc3.jar and some of
> > them break. So i will need to live with the 7.4.19 driver for a while.
>
> Without an actual failure it's tough to advise you here. You might try
> the URL option protocolVersion=2 or stringtype=unspecified to solve some
> of the more common problems people have come across with the upgrade as a
> workaround.
>
for example the following exception:
org.postgresql.util.PSQLException: Operation requires a scrollable ResultSet, but this ResultSet is FORWARD_ONLY
i have the ResultSet.last() call at least 290 times in my code so i should
adjust the relevant con.prepareStatement() to make the ResultSet scrollable.
I cannot do that at the moment.
I didnt post this actual problem, cause apart from the fact that it is natural
to happen, there could be others that i just dont know of yet. So due to lack
of time i didnt write about it at all.
> > One question, is there a way to get a hold of the Default TimeZone
> > instance of the JVM (lets call it default_TZ) and put all code that
> > alter it in some sort of
> > synchronized (default_TZ) {
> > TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> > // jdbc calls here that deal with timestamps without time zone
> > java.util.TimeZone.setDefault(null);
> > }
> > block?
>
> This seems unlikely to work. Everyone would have to get the default_TZ
> object before doing any TZ manipulation so they'd synchronzie on the same
> object. And there's no way you can control other code that just wants
> to print out a date. It's not going to synchronize itself on anything.
In java 1.4.2 (yes i know we are way old on this one also!), class TimeZone has:
private static TimeZone defaultZone = null;
Date in java 1.4.2 has a Calendar private field, and Calendar has a TimeZone.
All Date/Calendar manipulation eventually would access static field java.util.TimeZone.defaultZone.
If defaultZone was public, synchronizing on it would solve the problem,
unfortunately it is private.
Doing it with a "userland" object, as you say, would be impractical/impossible.
>
> Kris Jurka
>

--
Achilleas Mantzios