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

Reply via email to