Subject: Re: [PATCH v3 00/13] ci: include a Visual Studio build & test in our Azure Pipeline

From: Thomas Gummerer <[email-masked]>
Date: Mon, 7 Oct 2019 17:08:16 +0100

On 10/07, Junio C Hamano wrote:
> Johannes Schindelin <[email-masked]> 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/[email-masked]/

> 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,
> 		       );
> 
>