Date: Sun, 16 Jan 2022 10:48:53 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: pgsql-www@postgresql.org
Subject: Re: order of messages on www.p.o/list
Message-ID: <20220116164853.GA4336@telsasoft.com>
References: <20190221185641.GB24667@telsasoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190221185641.GB24667@telsasoft.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220116164853.GA4336%40telsasoft.com>
Precedence: bulk

Checking back.  This is still an issue.

The web list archives seems to sort things by the MUA's "Date" header (??)
without normalizing the timezones.  When I refresh the page, I expect the newer
messages to show up at the bottom.  It should be "append-mostly".  But with
good consistency I see messages shift around in both directions, and it makes
this a less useful/efficient way to follow the list.

On Thu, Feb 21, 2019 at 12:56:41PM -0600, Justin Pryzby wrote:
> Hi,
> 
> I'm interested to follow PG development but -hackers is too noisy for me to
> subscribe.  I tried following the list on www page few times per day.  However,
> sometimes I refresh the page, and I see that new mails have arrived somewhere
> in the middle (above the bottom mail), and I don't know which.  So I either
> lose time rereading list of mails (and mails themselves) or otherwise I miss
> mails which showed up somehere in the middle..
> 
> I'm refering to a page like this:
> https://www.postgresql.org/list/pgsql-hackers/since/201902210000/
> 
> Is that list ordered by time accounting for timezone ?  For example if someone
> in -11:00 sends a message at 14:00 UTC, does their message show up above somone
> else in -04:00 who mails at 13:00 UTC ?  Because their "Date:" header says
> 03:00.
> 
> Or perhaps it's an issue of the RFC822 "Date:" header vs. the received date?
> All the headers are just annotations, and so I suggest the page should be
> ordered not by the "date:" header set by the remote MUA but by the date in the
> most recent "Received:" header, added by the local MTA.  That avoids issue of
> wrong time setting on remote side.