Re: Timestamp Summary
От | Kevin Grittner |
---|---|
Тема | Re: Timestamp Summary |
Дата | |
Msg-id | s2e4e663.041@gwmta.wicourts.gov обсуждение исходный текст |
Ответ на | Timestamp Summary (Christian Cryder <c.s.cryder@gmail.com>) |
Ответы |
Re: Timestamp Summary
(Dave Cramer <pg@fastcrypt.com>)
|
Список | pgsql-jdbc |
Hi Christian, I don't know what this value is meant to convey, semantically. In your time zone, there was no such moment. If you were converting from a database which allowed October 35th in a timestamp column, would you feel compelled to preserve the value in the new database, or fix it? If it's from a different timezone, it doesn't tell you what moment it represents without knowing which timezone. It seems like you've worked around this by munging your runtime environment to something other than the actual timezone it would normally have. As long as this value sits in your database, every client which might want to read it (or similar values) must munge the runtime environment. What I'm proposing is that we need a fix so that when mapping a Timestamp object, which always represents an unambiguous point in time, to a "timestamp with time zone" value on the server (which also represents an unambiguous point in time), that they match, and when mapping a Timestamp object to a "timestamp without time zone" value on the server, that the client specify which time zone's representation of the moment to use. This would give you what you want by simply setting the time zone for your client JVM to a non-DST value -- the server setting wouldn't matter. I think it would also solve the problems reported by others. -Kevin >>> Christian Cryder <c.s.cryder@gmail.com> 07/25/05 12:47 PM >>> Hi Kevin, On 7/25/05, Kevin Grittner <Kevin.Grittner@wicourts.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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
В списке pgsql-jdbc по дате отправления: