On 10/07, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Date: Fri, 04 Oct 2019 08:09:25 -0700 (PDT) > > [...] > > X-Google-Original-Date: Fri, 04 Oct 2019 15:09:10 GMT > > [...] > > > > I am fairly certain that the latter is the actual `Date:` line sent to > > GMail, and GMail just decides that it will not respect it. > > If the submitting program said "Fri, 04 Oct 2019 15:09:10 +0000 > (GMT)" instead of "Fri, 04 Oct 2019 15:09:10 GMT", that would match > the format the MTA produced itself, I guess. I am kind-of surprised > if the problem is the use of the obs-zone format (RFC 2822 page 31), > but anything is possible with GMail X-<. Yeah, the obs-zone format did seem to be the problem. I just dug up the previous thread we had about this, where I confirmed that +0000 as the timezone worked just fine in my setup through GMail [*1*]. Note sure if the (GMT) would cause any problems, but I'd agree with avoiding it as you mention below to make sure GMail doesn't do anything funny with it. *1*: https://public-inbox.org/git/20190318214842.GA32487@xxxxxxxxxxxxxxxxxxxxxxxx/ > How does send-email write that date header? Matching that would be > probably the most appropriate, if possible, given that GGG was > written for send-email refugees, I guess ;-) > > Here is what its format_2822_time sub does, so +0000 without any > textual zone name, it is. > > return sprintf("%s, %2d %s %d %02d:%02d:%02d %s%02d%02d", > qw(Sun Mon Tue Wed Thu Fri Sat)[$localtm[6]], > $localtm[3], > qw(Jan Feb Mar Apr May Jun > Jul Aug Sep Oct Nov Dec)[$localtm[4]], > $localtm[5]+1900, > $localtm[2], > $localtm[1], > $localtm[0], > ($offset >= 0) ? '+' : '-', > abs($offhour), > $offmin, > ); > >
