Jonathan Feally wrote: > Jonathan Feally wrote: >> The correct operation would be to have the UTC timestamp stored in the >> database. When read from the database, it is not adjusted other than to >> add +0000 for a timestamp to the reformatted time. The patches >> http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=296c72b96ad148a812a0c681271bca52ca10c226 >> http://git.dbmail.eu/cgit/cgit.cgi/paul/dbmail/commit/?h=dbmail_2_2&id=01032167d087d675b92f6cca16527726db06ee84 >> >> only dealt with the reading part, not with insertion. So you should not >> be having an issue with this change. I will quickly test it out though >> to see if there is any difference for me. >> >> -Jon > And the results: (insertion with lmtp) > 2.2.11 - Date inserted is wrong, ie local time - thus adding the > timezone offset of the same as that of the insertion yields a valid > internaldate and matching when it was received. > 2.2.12 - Date inserted is wrong, ie local time - returned time is then > off by the timezone offset from insertion. > 2.3.5+ - Date inserted is UTC - returned time is then correct as we > don't tweak it, just add +0000 to it reformatted. > > 2.3.5+ uses dbmail_message_new() to create a new message in which the > internal_date is set to the current time, not done via the > SQL_CURRENT_TIMESTAMP. > 2.2.x is not having internal_date set, thus the fall back is to use > SQL_CURRENT_TIMESTAMP. So if the database server is not UTC, then time > will be wrong. > > > I've run out of brain power for tonight to do up a patch. Maybe you can > take a look at the internal date being set on dbmail-message.c line 884
Thanks a lot Jon, your triage put me on the right track. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
