A BUGNOTE has been added to this bug. ====================================================================== http://dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000079 ====================================================================== Reported By: scocking Assigned To: ilja ====================================================================== Project: DBMail Bug ID: 79 Category: IMAP daemon Reproducibility: always Severity: major Priority: high Status: feedback ====================================================================== Date Submitted: 30-Aug-04 12:39 CEST Last Modified: 15-Sep-04 17:23 CEST ====================================================================== Summary: INTERNALDATE reponses do not conform to RFC Description: The SnapperMail IMAP client is extremely strict in its IMAP protocol adherence, and requires that INTERNALDATE responses are formatted in "dd-mmm-yyyy hh:mm:ss +zzzz" format as per the RFC. DBmail always responds without the " +zzzz" timezone. ======================================================================
---------------------------------------------------------------------- ilja - 03-Sep-04 14:00 CEST ---------------------------------------------------------------------- fixed by doing the following: instead of using array magic etc, the two date functions date_imap2sql() and date_sql2imap() now use strptime() and strftime() to parse and format the date & time. date_sql2imap() outputs the timezone information with the date and time. fix has been applied to HEAD, dbmail_2_0_branch. A patch has been prepared for dbmail_1_2_branch. ---------------------------------------------------------------------- scocking - 08-Sep-04 10:15 CEST ---------------------------------------------------------------------- The supplied fix sends a timezone in its INTERNALDATE response, but the timezone is incorrect. The timezone presented is daylight time, when local time is not. An example seen by an IMAP client follows: 0295 > * 53 FETCH (UID 1290296 FLAGS (\Seen \Answered \Recent) ENVELOPE ("Wed, 8 Sep 2004 17:29:45 +1000" "Email subject" (({12} NIL "email" "domain.com")) (({12} NIL "email" "domain.com")) (({12} NIL "email" "domain.com")) (({15} NIL "simon" "mailguard.com.au")) NIL NIL NIL "<[EMAIL PROTECTED]>") BODY[HEADER.FIELDS (REFERENCES)] {2} INTERNALDATE "08-Sep-2004 17:33:11 +1100" <snip> The correct UTC offset for this location is +1000. +1100 is our daylight offset. I have triple-checked the server's timezone settings, and they're correct. All other software on this machine reports correct time. E.g. # date -R Wed, 8 Sep 2004 18:14:27 +1000 (I had a quick crack at fixing this myself. My system documentation doesn't show a tm_gmtoff member to struct tm, and I've never seen that myself. Could this be the culprit?) Simon. ---------------------------------------------------------------------- ilja - 08-Sep-04 10:36 CEST ---------------------------------------------------------------------- Hmm.. I just checked. It works here (I get +0100, which is correct here). So, you don't have tm_gmtoff in your tm struct. What system are you running? tm_gmtoff is a BSD & GNU extension. ---------------------------------------------------------------------- ilja - 08-Sep-04 13:37 CEST ---------------------------------------------------------------------- I'm getting more and more confused on how timezone stuff should work... ---------------------------------------------------------------------- ilja - 08-Sep-04 14:17 CEST ---------------------------------------------------------------------- hmm, of course it works correct here. We _are_ on daylights savings time. Hmm, I've just found a bug here. I managed to screw up something. I correctly get +0200 now. The bug's not in the patch I sent earlier. Anyway. I don't know what we should do here. I've posted a question on Usenet in comp.lang.c, perhaps we'll get a useful answer there. ---------------------------------------------------------------------- ilja - 15-Sep-04 16:32 CEST ---------------------------------------------------------------------- I haven't received any useful information from comp.lang.c... I'm currently at a loss how to solve this.. ---------------------------------------------------------------------- aaron - 15-Sep-04 17:23 CEST ---------------------------------------------------------------------- What if we just ask the database for a formatted time response? Bug History Date Modified Username Field Change ====================================================================== 30-Aug-04 12:39scocking New Bug 31-Aug-04 12:18ilja ETA none => < 1 day 31-Aug-04 12:18ilja Assigned To => ilja 31-Aug-04 12:18ilja Projection none => minor fix 31-Aug-04 12:18ilja Status new => confirmed 03-Sep-04 14:00ilja Bugnote Added: 0000216 03-Sep-04 14:00ilja Resolution open => fixed 03-Sep-04 14:00ilja Status confirmed => resolved 08-Sep-04 10:15scocking Bugnote Added: 0000225 08-Sep-04 10:15scocking Resolution fixed => reopened 08-Sep-04 10:15scocking Status resolved => feedback 08-Sep-04 10:36ilja Bugnote Added: 0000227 08-Sep-04 13:37ilja Bugnote Added: 0000228 08-Sep-04 14:17ilja Bugnote Added: 0000229 15-Sep-04 16:32ilja Bugnote Added: 0000249 15-Sep-04 16:33ilja ETA < 1 day => none 15-Sep-04 16:33ilja Priority normal => high 15-Sep-04 17:23aaron Bugnote Added: 0000252 ======================================================================