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
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 |