Re: [PATCH v3 00/13] ci: include a Visual Studio build & test in our Azure Pipeline
- From
Thomas Gummerer <t.gummerer@gmail.com>
- Date
- Oct 7, 2019, 16:08 UTC
- Message-ID
- <20191007160816.GB74671@cat>
- In-Reply-To
- <xmqq5zl15q1c.fsf@gitster-ct.c.googlers.com>
On 10/07, Junio C Hamano wrote:
Show 15 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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@hank.intra.tgummerer.com/
Show 22 quoted lines
> 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,
> );
>
>