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/