On Wed, Jul 09, 2003 at 05:55:42PM +0300, Timo Sirainen wrote:
On Mon, 2003-07-07 at 03:51, Stuart Henderson wrote:
One small glitch I have noticed is that when the client requests a list of messages sorted by date, the timezone is ignored.
It's not ignored, I just recently "fixed" it. Now it's properly fixed :)
test2 does not fix the internaldate issue here, I'm sorry to say.
This only recently started happening, I think as of rc4 or thereabouts. Up until that time, the internaldate was being reported properly. Now it's not. (This is for mbox formats.)
More details..
It appears that the internaldate is being taken from the "From " line (aka the "From_" line). Traditionally local delivery agents would write that line something like:
From mem@mv.mv.com Thu Jul 10 16:46:11 2003with no timezone info at all. However different local delivery agents would use various timezones, some using GMT or UT, and some using whatever local time was in effect. Plus, if you take a saved mbox with you to another timezone, all those timestamps are wrong. At some point in the past, we made the local delivery agents use timezone 0 and append the keyword UTC at the end, like this:
From mem@mv.mv.com Thu Jul 10 20:46:11 2003 UTC(I realize that standard mbox "From_" date is written in local timezone with no timezone qualifier, but I really dislike that amount of ambiguity so I did what I did.)
Up until recently dovecot was returning the correct internaldate. Recently it has started returning the time string as if it were the local time, and ignoring the timezone.
I suspected that you were being more rigorous about ignoring known obsolete forms including keyword timezones, so I changed to:
From mem@mv.mv.com Thu Jul 10 20:46:11 2003 +0000with no change in behaviour. Apparently you are being more rigorous about enforcing standard mbox "From_" format?
Would it hurt to parse timezone information on the "From_" line if it's there?
mm