Open sevzas opened 12 years ago
According to RFC3501:
SENTON
Messages whose [RFC-2822] Date: header (disregarding time and timezone) is within the specified date.
Does that not imply that time and timezone will simply be ignored by the server when performing the SEARCH command. I don't think it says that it's illegal to specify them as part of the date, so I'm not sure it's incorrect really?
Smiley22,
That's what I thought also. But if you look carefully at section 6.4.4 you'll see:
ON <date>
SENTBEFORE <date>
SENTSINCE <date>
SINCE <date>
And then if you look in the "formal synthax" in section 9, you'll see:
date = date-text / DQUOTE date-text DQUOTE date-text = date-day "-" date-month "-" date-year date-day = 1*2DIGIT date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" date-year = 4DIGIT
[continuing previous post / accidentally posted] So it's pretty explicit that the format of the parameter of any of the clauses ON SENTBEFORE SENTSINCE SINCE is formatted as dd-MMM-yyyy or "dd-MMM-yyyy"
ah okay you're right then!
what about time can u pls give example
@bhavikac it appears that in the IMAP spec RFC 3501 time is specified as HH:mm:ss zzzzz where HH is the 24 hour time, zzzzz is the timezone expressed as +/- offset from GMT (see "time" and "zone" in section 9, for example "+0000" is GMT) of http://www.faqs.org/rfcs/rfc3501.html
Please be cautioned - as I stated in my original post nearly 4 years ago, time isn't officially supported in the IMAP spec for SEARCH ON and SENTON and because of this, the various IMAP server were observer to handle time differently. Perhaps the command you're looking to use supports time, please make sure.
The output for IMAP SEARCH ON and SENTON parameters has the time and timezone which should not be there according to RFC3501. http://www.faqs.org/rfcs/rfc3501.html . The format should be dd-MMM-yyyy with optional quotes.
What I've seen is that gmail IMAP server accepts the time and timezone and appears to ignore it. On the other hand, IceWarp 10.3.5 accepts the time and timezone, but returns incorrect results - so beware!