Re: [Nmh-workers] Date Parsing Problems.

[Ralph Corderoy]

Hi kre,

> > 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).

Sorry, the context is a lexer that's only intended for Date headers, and
similar sources.  I agree it's rational;  that's the format I use.  :-)
I think Postel was wrong in a modern context and we should be less
forgiving, https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00,
but on the other hand, the lexer should continue to handle Date formats
in vogue thirty years ago that are still sitting in +inboxes.

> There is no way to get from a numeric offset to a timezone unless one
> makes bizarre assumptions (like only the US matters).

Agreed;  it's just a numeric offset.

> >    * 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.

And, for me coming to it new, the hoops it jumps to makes the logic
harder to follow.

> And that assumes that summer time means 1 hour, which isn't univesally
> true, there are zones that alter the clocks by 30 minutes...

Yep.

> 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).

Right, so it's only turning PST on some old Date header into a `±hh:mm'
that needs to remain.

> Simplify this stuff into oblivion.

I'll keep chipping away.  I seem to be gardening at the moment.  Getting
rid of the dead, diseased, and crossing branches in order to see what's
left.  Thanks for the parsedate() pointer.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy