[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Date Parsing Problems.

From: Robert Elz
Subject: Re: [Nmh-workers] Date Parsing Problems.
Date: Sun, 23 Apr 2017 19:48:42 +0700

    Date:        Sun, 23 Apr 2017 10:32:24 +0100
    From:        Ralph Corderoy <address@hidden>
    Message-ID:  <address@hidden>

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]