Dates in Mush

[Barton E. Schaefer]

On Sep 20,  9:58am, lupe christoph wrote:
} Subject: Re: Dates in Mush
}
} "MET DST" comes from zoneinfo:
} 
} # @(#)europe 1.3 89/02/13 SMI; from Arthur Olson's 3.1
} 
} 	...
} Rule    M-Eur   1986    max     -       Mar     lastSun 2:00s   1:00    " DST"
} Rule    M-Eur   1986    max     -       Sep     lastSun 2:00s   0       -
} 	...
} Zone    MET             1:00    M-Eur           MET%s
} 	...
} 
} This means that "MET" is suffixed by " DST" in the period "Mar lastSun 2:00s"
} till "Sep lastSun 2:00s".

Hm.  Looks as though something like

  Rule    M-Eur   1986    max     -       Mar     lastSun 2:00s   1:00    S
  Rule    M-Eur   1986    max     -       Sep     lastSun 2:00s   0       -
  	...
  Zone    MET             1:00    M-Eur           ME%sT

would produce what B-news (and mush) are expecting for zones.

} You might want to ask seismo!elsie!tz about the names.

OK, tz is on the To: line.  Maybe he (Arthur?  Is that you?) could shed
some light on the subject.  As nearly as I can tell, the B-news parser is
prepared to handle arbitrarily mixed cases, periods between the letters,
and practically every other combination *except* two words separated by a
space.  Mush is a less robust about mixed cases and so on because it
doesn't expect to be parsing anything but machine-generated date strings.

} 	> Thanks for the info.  I think I'm going to try to find a
} 	> better way to parse for it, though.  It should be possible
} 	> to recognize it without explicitly reading it into a string,
} 	> e.g. match it literally in the sscanf format or something.
} Regular expressions ?

Well, actually, what you did isn't too bad in theory but is overkill in
all but one of the cases.  Even if we do read it into a string, it's not
necessary to add a new sscanf call every time; just add the %3s (you used
%4s, but you should have allocated a 5-char buffer for that) after the
%7s that is already there.  Note that the comparisons are for things like
(sscanf() >= 5) in nearly all cases; the zone is already expected to be
missing, so it won't hurt to also ignore a missing DST (not) tacked on
after the zone.  The only one where you need the explicit match is one
where the zone name appears in the middle of the string.

-- 
Bart Schaefer						schaefer at cse.ogi.edu