From: | "emergency(dot)shower(at)gmail(dot)com" <emergency(dot)shower(at)gmail(dot)com> |
---|---|
To: | Christian Cryder <c(dot)s(dot)cryder(at)gmail(dot)com> |
Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Timestamp Summary |
Date: | 2005-07-25 22:51:58 |
Message-ID: | bdf1a09805072515515f30d261@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 7/25/05, Christian Cryder <c(dot)s(dot)cryder(at)gmail(dot)com> wrote:
> [...]
> This piece of code only needs to get executed when the connection is
> first opened to the DB, and from that point on it will ensure that the
> db is in functionally the same timezone as the server (taking DST
> on/off into account as well). In other words, if my client is running
> in MST w/ DST turned off, the server will be configured to etc/gmt+7,
> and any dates I insert will be left untouched.
>
> That make sense?
Hi Christian,
Besides setTimestamp(int, Timestamp) and getTimestamp(int) we have the
more general methods setTimestamp(int, Timestamp, Calendar) and
getTimestamp(int, Calendar).
If I understand the specs correctly, calls to the methods without a
Calendar parameter should be equivalent to the call to the other
methods with a Calendar that has time zone TimeZone.getDefault().
From this it follows that modifying the VM's default time zone is a
non-solution.
Moreover in my opinion the database server's time zone should be
ignored by any client (application and JDBC driver) code.
Regards,
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Tomasz Szczeszynski | 2005-07-25 22:59:27 | UNSUBSCRIBE |
Previous Message | emergency.shower@gmail.com | 2005-07-25 22:02:16 | Re: Timestamp weirdness |