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: normal
Status: feedback
======================================================================
Date Submitted: 30-Aug-04 12:39 CEST
Last Modified: 15-Sep-04 16:32 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..
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
======================================================================
