On Sun, 2005-05-15 at 09:49 +0000, Aaron Stone wrote:
> Not to discount the value of this discussion, but in the present moment we
> need to figure out a proper fix for the bug described above that does not
> compromise the dates which have already been entered into people's
> databases, or is at least distinct from those dates so that a dbmail-util
> function can be written that will correct errant dates from previous
> versions.
Pg has no problems. SQLite and MySQL use the $TZ variable which should
be set to GMT for correct operation.
What we need is a program that scans timestamps for:
=~ /\[+-]\d{3,4}\s*$/
in time fields and alters the timestamp until that last part would be
zero. Any other time stamps are wrong already.
Maybe another option is to remove the "+0000" and use whatever timezone
the remote feels like. With Mysql this is remote's $TZ variable and with
sqlite, they're welcome to change that gmtime() back into a localtime
()...
... or we can set localtime() and give a nasty warning if(getenv
("TZ")&&strcmp("GMT",getenv("TZ"))) at startup..
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
