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 Paul? -Jon -- Scanned for viruses and dangerous content by MailScanner _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
