From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 3C6BD1F619; Sun, 1 Mar 2020 23:31:39 +0000 (UTC) Date: Sun, 1 Mar 2020 23:31:38 +0000 From: Eric Wong To: Leah Neukirchen Cc: meta@public-inbox.org, "Eric W. Biederman" Subject: [pushed] msgtime: assume +0000 if TZ missing when using Date::Parse Message-ID: <20200301233138.GA25934@dcvr> References: <87h7zfemur.fsf@vuxu.org> <20200225092303.GA382@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200225092303.GA382@dcvr> List-Id: Eric Wong wrote: > Leah Neukirchen wrote: > > 1) RFC5322/822 invalid Date: headers should be parsed more gracefully > > > > Some old mails had Date: headers without time zones, e.g. > > Date: Sat, 27 Sep 1997 10:02:32 > > > > This results in public-inbox asserting this is the current date. > > But this assumption makes no sense (literally every other guess > > would be more likely), and also results in these messages showing up > > on the first page of the archive. Furthermore, sorting is then not > > stable, pressing F5 make the threads jump around. I'd recommend > > falling back to +0000 instead. > > I think a fallback to +0000 makes sense, too. > It's not a new bug in 1.3.0 (which makes Date::Parse optional). > > Looks like that regression was introduced a while ago in > commit ae80a3fdb53d70142624f2691ed8ed84eddda66b > ("MsgTime.pm: Use strptime to compute the time zone") > > Cc-ing Eric W. Biederman in case he has any input on this. > ------------8<------------ > Subject: [RFC] msgtime: assume +0000 if TZ missing when using Date::Parse Pushed as commit d857e7dc0d816b635a7ead09c3273f8c2d2434be with a more descriptive commit message: msgtime: assume +0000 if TZ missing when using Date::Parse Some old emails don't have timezone offsets, since our Date::Parse code path takes a liberal interpretation of dates, fallback to using "+0000" as the timezone offset since it's closer to the actual date of the message than whatever the current date is. Reported-by: Leah Neukirchen Link: https://public-inbox.org/meta/87h7zfemur.fsf@vuxu.org/ Fixes: ae80a3fdb53d7014 ("MsgTime.pm: Use strptime to compute the time zone") Thanks