Re: work in progress: timestamp patch

From: Christian Cryder <c(dot)s(dot)cryder(at)gmail(dot)com>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: Oliver Jowett <oliver(at)opencloud(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: work in progress: timestamp patch
Date: 2005-07-26 19:47:40
Message-ID: 90876a9e05072612478f36c41@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On 7/25/05, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> One of the times he is trying to stick in the db is a non-existant
> time if it is associated with a time zone
>
> stmt.execute("INSERT INTO Foo (t1) VALUES ('2005-04-03 02:29:43.0')");
>
> in any US timezone this time does not exist. In US/Mountain timezone
> this inserts as 2005-04-03 03:29:43.0' note the hour has incremented from
> 2 to 3

Just a clarification guys.
a) this time is only invalid in a US timezone that uses Daylight Savings
b) if you insert it via Statement like this, it inserts into the db
just fine; if you insert it using PreparedStatement the value will get
munged
c) once you have the value in the DB, the question is: "How can I read
the value and then rewrite it without munging it"

The only answer to c right now is
a) reconfigure both your client and your server to run in UTC (or some
other non-DST zone)
b) reconfigure your client to turn DST off, and then adjust the server
zone programatically just for the scope of the connection (that was
what my little patch was about)

Neither of these solutions is particularly appealing. I'm surprised
the basic data-integrity aspects of this issue don't bother people
more...

Christian

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Scott Goldstein 2005-07-26 22:56:13 Client Connection vs. JDBC Connections vs. Postgres processes
Previous Message Christian Cryder 2005-07-26 19:40:29 Re: Timestamp Summary