Date: Sun, 23 Apr 2017 10:32:24 +0100
From: Ralph Corderoy <ralph(_at_)inputplus(_dot_)co(_dot_)uk>
Message-ID:
<20170423093224(_dot_)6ECB91F983(_at_)orac(_dot_)inputplus(_dot_)co(_dot_)uk>
| 2017-04-23 isn't valid input,
Why? Looks like a fairly rational way to write dates to me (20170423 might
be more standard, but the extra punctuation makes it much easier to read).
| Who here knows about the lexer's
|
| /* If the following is #defined, a timezone given as a numeric-only
| * offset will be treated specially if it's in a zone that observes
| * Daylight Saving Time
That's utter gibberish. There is no way to get from a numeric offset
to a timezone unless one makes bizarre assumptions (like only the US matters).
| For instance, during DST, a Date: like
| * "Mon, 24 Jul 2000 12:31:44 -0700" will be printed as "Mon, 24 Jul
| * 2000 12:31:44 PDT". Without the code activated by the following
| * #define, that'd be incorrectly printed as "...MST". */
That almost might be appropriate in the US (perhaps even Canada) but it
makes no sense in general.
| #define ADJUST_NUMERIC_ONLY_TZ_OFFSETS_WRT_DST 1
|
| As it's set, the lexer knocks an hour off the timezone if DST.
|
| tm = localtime (&tw->tw_clock);
| if (tm->tm_isdst) {
| tw->tw_flags |= TW_DST;
| tw->tw_zone -= 60;
| }
And that assumes that summer time means 1 hour, which isn't univesally
true, there are zones that alter the clocks by 30 minutes...
| /* Get the timezone for given offset.
| * This used to return a three-letter abbreviation for some offset
| * values. But not many. Until there's a good way to do that,
| * return the string representation of the numeric offset. */
Forget about "good way to do that" - there isn't, the alphabetic abbrevs
are an anachronism, and these days are almost never used in e-mail any
more (except sometimes as a comment).
| I don't think "PST", etc., will ever return?
Agreed. Simplify this stuff into oblivion. If we really need a
more general string date parser, look into Steve Bellovin's parsedate()
or one of the enhanced versions of that that are floating around, it
does a pretty good job with all semi-rational date/time strings (and
plenty of non-rational ones as well.)
The vast majority of other date parsers I have ever looked at are full
of errors, and ugliness. (Well, parsedate is as well, but at least it
mostly gets things right.(
kre
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers