From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
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 9492F1F454;
	Sun,  3 Nov 2019 09:02:42 +0000 (UTC)
Date: Sun, 3 Nov 2019 09:02:42 +0000
From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: HTTP::Date replacing Date::Parse [was: TODO: remove done items, add
 some more]
Message-ID: <20191103090242.GA28983@dcvr>
References: <20190713215455.31863-1-e@80x24.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190713215455.31863-1-e@80x24.org>
List-Id: <meta.public-inbox.org>

> +* consider using HTTP::Date instead of Date::Parse, since we need the
> +  former is capable of parsing RFC822-ish dates, used by Plack, and
> +  the latter is missing from OpenBSD and maybe other distros.

Ugh, HTTP::Date will try to use Time::Zone under the hood if
available for non-conformant dates.  And Time::Zone is part of
the same TimeDate package as Date::Parse, which I was trying to
stop depending on...

At least one incompatibility I've found is the inability of
HTTP::Date to handle the "+1" (yes, single digit) timezone
offset which we have a test case for in t/msgtime.t

There's probably a few more wacky historical cases which we lack
test cases for.  Hell, there's even a case of 3-digit years in
LKML history which we special-case for.

So, I'm not sure it's worth it...  The good thing is that going
forward, dates seem to much more conformant as clients got
better.  So there's only a finite set of historical special
cases which we'd need to deal with.