> Oh? I don't recall a mail where you said this. Was this recently? Is it
> possible your post got lost? Did anyone else see this?
Uh. You're right, apparently it did get lost... I didn't get it back
from the list. Here is the text:
| To: [EMAIL PROTECTED]
| Subject: more dtimep fixes
| Date: Wed, 06 Sep 2000 19:09:54 -0400
| From: Shantonu Sen <ssen>
|
| So, I think some of the time discrepencies that Dan was seeing
| in his scan lines (using -form scan.time) might have been because
| the dtimep parser was try to interpret some text time zones (like
| MET), which it didn't explicitly know about, as military time zones.
|
| I've taken out military zones, and this appears to have fixed up some
| of the errant parsing when compared to 1.0.4. Dan, can you do
| another diff to check this (I just checked in the changes). Also, you
| will still see many differing lines because dtimep no longer treats
| timezone-unqualified mails as having originated in the current zone.
| Those emails will show up as GMT, which I think is totally reasonable.
|
| Also, since a lot of the mts changes have settled down, I will
| be moving the code from zotnet/mts to mts, which will make the
| entire zotnet tree deprecated. The only changes will be the
| changes in the Makefiles and the path to the header files (I'll
| update these, just point to the new location for future reference).
> Looking at the ChangeLog, I see you also fixed the date-parsing bugs in your
> new dtimep.lex. Were military time zones supported in the old dtimep.lex?
> Did they cause a problem there? If not, why not? [Just want to make sure
> removing military time zone support is the right fix.]
The old parser did parse military zones, but the technique was a little
different, and it used things like Start Conditions. Perhaps because my
code doesn't use context in the same way, the problem was manifesting
itself. Removing the military zones certainly corrected it. The other
option is to make the parser finer-grained with start conditions to specify
whether it should even try to deduce anything. We can try this if
military support is missed.
> I have to shed a small tear as a U.C.I. alum. for the removal of the UCI
> mascot. ;^> (See docs/README.developers for an explanation of "zot".)
We can leave the zotnet/ directory blank and make everyone wonder ;-)
Seriously, though, I think having a handful of functions in this other
subdirectory over here was confusing without any obvious benefits.
Shantonu
