Hallo everyone, While doing testing on dbmail 2.0rc2 with Micro$oft Outlook using IMAP to grab mail from dbmail, I found an interesting problem.
I'm using postgresql 7.2 for the db backend and the sql/postgres/create_tables.pgsql script specifies the following for the physmessage table: CREATE SEQUENCE physmessage_id_seq; CREATE TABLE physmessage ( id INT8 DEFAULT nextval('physmessage_id_seq'), messagesize INT8 DEFAULT '0' NOT NULL, rfcsize INT8 DEFAULT '0' NOT NULL, internal_date TIMESTAMP, PRIMARY KEY(id) ); The problem is that specifying TIMESTAMP to PostgreSQL 7.1 and above will make PostgreSQL default to what they call 'timestamp with time zone' which looks like 2004-02-24 14:58:42.167476-05 and is internally known as timestamptz. This causes Outlook (didn't see this behavior on KMail with IMAP though), to show the Received Date as 11/03/1979 12:00AM which of course isn't correct. Upon Outlook's first display of a new message, it shows the correct Received date but then something updates (or you click on the message) and the date gets transformed to 11/03/1979 12:00AM and thereafter stays that way within Outlook. There wouldn't be any problem if it were not for the date_sql2imap function expecting to see a mysql format date, as specified in imaputil.c: -- excerpt from imaputil.c -- /* * convert a mySQL date (yyyy-mm-dd hh:mm:ss) to a valid IMAP internal date: * 0123456789012345678 * dd-mon-yyyy hh:mm:ss with mon characters (i.e. 'Apr' for april) * 01234567890123456789 * return value is valid until next function call. * NOTE: sqldate is not tested for validity. Behaviour is undefined for non-sql * dates. */ char *date_sql2imap(const char *sqldate) { int mon; if (strlen(sqldate) != strlen("yyyy-mm-dd hh:mm:ss")) { strcpy(_imapdate, "03-Nov-1979 00:00:00"); return _imapdate; } -- end excerpt from imaputil.c -- date_sql2imap specifically returns the 03-Nov-1979 00:00:00 date/time when the sql date returned by the db backend is longer than the default date format it expects to convert. I don't know if the code should be changed to handle the timezone or not, but I do know that I was able to fix this behavior and have not seen any problems with the following specification for the physmessage table: CREATE SEQUENCE physmessage_id_seq; CREATE TABLE physmessage ( id INT8 DEFAULT nextval('physmessage_id_seq'), messagesize INT8 DEFAULT '0' NOT NULL, rfcsize INT8 DEFAULT '0' NOT NULL, internal_date TIMESTAMP WITHOUT TIME ZONE, PRIMARY KEY(id) ); So that's about it for that... any ideas as to what should be done? Blessings in Jesus, Paul F. De La Cruz