[tin-bugs] Weird timezone offsets throws tin date parser off

[Urs Janßen]

On Mon, Jun 23, 2025 at 01:35:35AM +0300, Valery Ushakov wrote:
> gmane.os.netbsd.ports.arm at news.gmane.io (and other groups there,
> that gate netbsd mailing lists) has messages from one guy with what I
> assume to be an artisanal show-off TZ offset.  E.g.:
> 
>   From: "William A. Mahaffey III" <wam at hiwaay.net>
>   Message-ID: <dfced155-d1fb-6de1-c76c-326b1d18e92d at hiwaay.net>
>   Date: Wed, 25 May 2016 10:59:40 -0453.75

RFC 5322 3.3
|   zone            =   (FWS ( "+" / "-" ) 4DIGIT) / obs-zone

-> illegal (yes, I've also cheked obs-zone in the same RFC, section 4.3)

> This throws off tin's date parser and it tells me (in the article
> view), that the article is from
> 
>   Wed, 01 Jan 2070 02:59:59

the "problem" is that parsdate() either returns a t_time() value
(date is valid) or -1 (date is invalid).
the later is turned into (time_t) 0 to have a valid date when assigned to
the articles date field (wich basically holds a time_t value) and that is
1970-01-01 00:00:00 +0000 (UTC).

> It would be nice if the date parsing code was a bit more conservative.
> Ignoring bad TZ offset would give the date that is only a few hours
> off, not several decades.

but where do you draw the line here and at what point is a defective date
header defective? is a day with 64 minutes per hour or 26 hours ok? or a 
february with 30 days? no? why not?