Geo Carncross wrote: > On Thu, 2005-05-12 at 17:08 +0000, Aaron Stone wrote: > > >> Geo, would you this up as a patch against current dbmail_2_0_branch SVN? > > > > > > Attached. This means dbmail will mandate GMT/UTC in the SQL-side. > > > > Does that change current behavior? I haven't been following the issue yet, > > as to whether we are keeping dates in the server's local time or in GMT -- > > is that the entire problem so far? > > It can. It depends on the administrator. I recommend the following > changes to: > > Pg driver should to do this somewhat early (after bringing connection > up): > SET SESSION TIME ZONE GMT;
I think to be pedantically correct, this should be UTC, not GMT. I seem to recall that they're not completely equivalent. > Sqlite driver needs to have a: > localtime_r(&now, &tm); > turned into: > gmtime_r(&now, &tm); > > > Now: Pg's server RIGHT NOW should be started with TZ=GMT, and the above > isn't needed. SQLite can have dbmail started with TZ=GMT and you're > okay. For PostgreSQL, it doesn't matter what time zone the server is running in, fortunately, as long as you use 'timestamp with time zone' as the column type (which I believe is the case here). Then you just use the SET SESSION TIME ZONE command on the client side. As far as I know, most PostgreSQL installations start the database using the local time zone, so clients will need to set their time zone differently if they want a different time zone. I think it would be very unwise for dbmail to rely on the time zone of the database. I'm actually somewhat surprised to find that the PostgreSQL client code doesn't check the TZ environment variable at startup and set the session time zone automatically based on it. -- Kevin Brown [EMAIL PROTECTED]
