On Sun, May 15, 2005, Kevin Brown <[EMAIL PROTECTED]> said: > Geo Carncross wrote: >> On Fri, 2005-05-13 at 01:49 -0700, Kevin Brown wrote: >> > 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. >> >> UTC doesn't honor leap seconds. I don't know of any other (earthly) time >> zone that doesn't, so I still maintain GMT is better for dbmail. > > Ah, right. > > Well, if the other timezones adjust for leap seconds, then they do so > relative to UTC, right? So if dbmail needs to truly be timezone > agnostic, then it should use UTC, yes? The clients can then figure > out what adjustments to make to the dates that are presented to them > based on their local timezone.
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. Aaron
