A BUGNOTE has been added to this bug. ====================================================================== http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000079 ====================================================================== Reported By: scocking Assigned To: ====================================================================== 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: 29-Mar-05 20:29 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? ---------------------------------------------------------------------- ilja - 15-Sep-04 17:28 CEST ---------------------------------------------------------------------- Of course! We only need to find the places where we ask the database for an INTERNALDATE, but I'm thinking we only ask for it in this IMAP code.. It might just work. I only hope that our way of saving the INTERNALDATE (without timezone) doesn't stand in the way. Ilja ---------------------------------------------------------------------- ilja - 16-Sep-04 11:53 CEST ---------------------------------------------------------------------- Last option doesn't work.. Back to square 1 ---------------------------------------------------------------------- paul - 29-Mar-05 20:29 CEST ---------------------------------------------------------------------- I've done a (hopefully) portable version of date_sql2imap that does not rely on GNU extensions. It uses tzset(3) to determine the gmt offset, and uses the tm_isdst field in tm structs to add a 1 hour offset if dst is relevant for the time being parsed. I'm pretty sure this will work! I'm uploading the test implementation... 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 15-Sep-04 17:28ilja Bugnote Added: 0000253 16-Sep-04 11:53ilja Bugnote Added: 0000266 23-Nov-04 23:11michaelg Bug Monitored: michaelg 29-Nov-04 11:20ilja Assigned To ilja => 29-Mar-05 20:29paul Bugnote Added: 0000640 ======================================================================