Currently, getmail (unless disabled) inserts a Received header with UTC time information. In my opinion, local time would be preferrable and (on my machine, at least) can easily be obtained with the following trivial patch (against the currently stable 4.3.3, but it cleanly applies to the latest 4.3.6 as well).
diff -ur getmail-4.3.3-orig/getmailcore/message.py getmail-4.3.3/getmailcore/message.py
--- getmail-4.3.3-orig/getmailcore/message.py 2005-04-22 09:58:02.000000000 +0200
+++ getmail-4.3.3/getmailcore/message.py 2005-04-22 09:58:21.000000000 +0200
@@ -158,8 +158,7 @@ class Message(object):
if self.recipient is not None:
content += ' for <%s>' % self.recipient
- content += '; ' + time.strftime('%d %b %Y %H:%M:%S -0000',
+ content += '; ' + time.strftime('%d %b %Y %H:%M:%S %z')
gen = Generator(f, mangle_from, 0)
# From_ handled above, always tell the generator not to include it
However, as the python docs say: "The use of %Z is now deprecated, but the %z escape that expands to the preferred hour/minute offset is not supported by all ANSI C libraries." I checked this on Win XP, and in fact, it doesn't work there as it should to comply with RFC 2822. Since I've seen some Windows users on the getmail mailing list, this is probably the reason why the '-0000' time zone was hardcoded into getmail in the first place and the above patch probably will never make it to upstream.
But, assuming that all Gentoo-supplied ANSI C libaries do support the "%z" format, maybe it's possible (and worthwile -- yes, I am aware that this is only a minor cosmetic issue, but still ... ;) to incorporate this patch into the "Gentoo edition" of getmail.
Thanks for your (local ;) time!
Steps to Reproduce:
Created attachment 56911 [details, diff]
The patch file once more as an attachment
This patch should be sent upstream. If it is accepted then all is good, if not we will have a better idea of what else this might impact. Supporting trivial patches like this is an additional overhead.
Again I have to agree with Benjamin.
In fact, I'm going to resolve this as NEEDINFO until Lars gets an answer from upstream. REOPEN when you get it.
Sorry, I have somehow forgotten to follow up on this (isn't my top priority, either :)). But I'll propose a slightly extended patch (checking for a sane time.strftime('%z') implementation) to the getmail users' mailing list and report back here as soon as I have an answer.
Ok, so here is what Charles Cazabon said to my proposal:
> > I was wondering if it is possible to have the local time instead of UTC in
> > the Received header inserted by getmail.
> As you noted, it can be very easy. However, it's misguided. Received:
> headers are used to track mail problems, and UTC is far more useful in this
> respect, as much/most mail crosses multiple time zones.
> The qmail MTA, for example, also uses UTC in all Received: headers.
> > I know, this is just a tiny cosmetic issue, but I still hope it might help
> > someone. (I for one prefer the local time format a lot because I always get
> > the calculations the wrong way round ... ;-) and, yes, sometimes, I do find
> > it useful to know when a message was received...)
> Having a different timezone in each Received: header makes it far more
> difficult to determine what happened and when, and how long each hop took.
> Feel free to use your patch on your own system, but I won't include it in
( The thread is archived at http://news.gmane.org/find-root.php?group=gmane.mail.getmail.user&article=1858 )
It seems, the whole idea wasn't a very clever one to begin with... :-@
Thus, instead of reopening, I close this bug, assuming your approval. Sorry for the noise!