From: Karsten H. <Kar...@gm...> - 2005-05-23 20:20:24
|
On Mon, May 23, 2005 at 04:13:25PM +1000, Andrew McNamara wrote: > > Bill recently checked in this change: > > date: 2005/05/16 03:37:56; author: ballie01; state: Exp; lines: +23 -4 > 15MAY2005 bga > A change to the datetime parsing changed the default datetime object > from localtime to UTC. This update returns the default to localtime > and adds a new variable, 'useUTCtimeValue' to control the default > value of a datetime object. Setting it to 1 will cause the datetime > object to reference the UTC time, 0 will cause the datetime object to > reference the client's local time zone. I do believe the application should have to know what time zone it requested a date time object at. > The results are not idempotent - a DateTime saved to the database comes > back adjusted by the current timezone offset. Depending on the setting > of useUTCtimeValue, either PG_TIMESTAMP or PG_TIMESTAMPTZ is wrong. If > an application used only one of these types, useUTCtimeValue could be > set appropriate, but if the application uses both, it's in trouble. That application is in trouble anyways. There cannot be any clarity when ambigous programming is used. I believe that pyPgSQL shouldn't (have to) fuzz around with adjusting the date/time data in the first place. Any responsible application will issue "set timezone ...;" appropriately for every session. Or else (in case it needs datetimes adjusted to many different time zones within one and the same session) it will use "select ... at time zone ...;". Everything else is broken (unless there are errors in my thinking) and pyPgSQL should not be blamed for it. > Operating on timezones is like waltzing through a minefield - I'm not > sure what to suggest to fix this, but I think the PG_TIMESTAMP type > ("without time zone") should make the round-trip to postgres and back > unmollested by default. That is quite true. If one retrieves a "timestamp" field there is no timezone information to be had as there is none. Maybe I am missing the real issue ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 |