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;
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.
Mysql definately needs TZ=GMT in the safe_mysqld script (or similar-
anyone know of a way to get dbmail to do it?)
I _ALWAYS_ run my services with TZ=UTC (or TZ=GMT) and I recommend
others do the same. I don't know if dbmail can force mysql to do the
right thing, but at the very least, these things should be documented:
something like
MYSQL USERS:
You _MUST_ set TZ=GMT in your safe_mysqld script (or however mysqld is
started on your system) or your time stamps will be WRONG. This is
because DBMAIL NO LONGER attempts to do funky time zone conversion that
will only be undone by the client anyway.
POSTGRESQL USERS:
DBMAIL sets the session timezone to GMT. You don't have to do anything.
SQLITE USERS:
DBMAIL always uses GMT when speaking to SQLite. You don't have to do
anything UNLESS you're converting an existing SQLite dbmail-
installation. In which case, we'll need you to (perform XYZ operations)
OR JUST SAY FUCKIT and change the gmtime_r in ... back into localtime_r.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
