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

> On 10/07, Junio C Hamano wrote:
> > 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/

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