Re: Date handling.

From: Russ Allbery <rra@stanford.edu>
Date: Apr 25, 2005, 01:32 UTC
Message-ID: <87br83wsj2.fsf@windlord.stanford.edu>
In-Reply-To: <20050425012216.GH29939@delft.aura.cs.cmu.edu>

Jan Harkes <jaharkes@cs.cmu.edu> writes:

> As Russ mentioned, that probably doesn't work with daylight savings
> time. However I did some testing and it looks like the following lines
> around mktime make it work as we would expect.

>     tm.tm_isdst = -1;
>     then = mktime(&tm);
>     then += tm.tm_gmtoff;

> Attached is the program I used to test it, it seems pretty much unfazed
> by changes to the TZ environment variable. Although I tested around a
> daylight savings time switch, I'm still not 100% sure if it doesn't mess
> up in some corner case.

I don't know what sort of portability you're striving for, but many platforms don't have tm.tm_gmtoff. But reimplementing mktime from scratch isn't particularly hard so long as you don't need some of the "extra" features of mktime (canonicalizing a struct tm or accepting out of range values and doing the "right thing").

I came in a little late to this discussion, but I gather that the overall goal here is parsing RFC 2822 dates. You're all certainly welcome to take the code that I wrote for INN to do this if you wish, although it parses the full RFC 2822 syntax and therefore may accept things you consider insane (comments, newlines, etc.) Or you're welcome to cherry-pick bits and pieces out of it (like mktime_utc). This code has a fairly extensive test suite and has also been tested against the old INN parsedate function on ~2M Usenet articles.

All of this code is my own work, and as far as I'm concerned it's in the public domain or as close of an approximation that one can get to that in your local legal environment.

The code is largish and needs some Autoconf support, so I won't just send it to the list unless someone wants it, but let me know if you do. You can also get it by downloading INN from:

    <ftp://ftp.isc.org/isc/inn/snapshots/>

(getting the latest CURRENT snapshot) and looking in lib/date.c. You don't need the parsedate_nntp stuff, and you probably don't care about parsedate_rfc2822_lax, which accepts common violations of RFC 2822 syntax found in Usenet messages. The test suite is in tests/lib/date-t.c.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>