Re: Timestamp Summary

Hi Kevin,

On 7/25/05, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> As someone who is interested in timestamp columns only to hold actual
> moments in time, I'm very uncomfortable with Christian's proposed "fix".

But this isn't how the DB works...from the command line sql interface,
or via the Statement implementation, you can easily insert "invalid"
(eg. not-valid-DST) timestamps. So how does this mesh with my data
integrity concerns - if I read a timestamp from jdbc, and then turn
around and write that same timestamp, it seems to me the object
shouldn't get munged. And right now, it does.

> since you can't actually create a Timestamp object within
> a JVM set to the correct time zone to represent what he wants

Just to be clear - you CAN create a Timestamp for these objects (it
just requires having DST turned off in order to do it). And that's
really the rub - the DB contains data that Timestamp thinks is invalid
(unless DST is turned off).

We need something more than a "configure both your client and server
to use the same non-DST timezone", which is currently the only option
(although my suggestion still requires us to set the client into
non-DST programatically).

All that said, I am still basically sympathetic with your concern. It
seems a bit hacky to me too, to be forcing the timezone on the server,
just so date munging doesn't happen. I'd still like a solution where I
can re-insert the date without munging, even if the server and the
client are both running w/ DST turned on. So if someone can think of a
way to do that, that would be even better...

Christian