Shantonu Sen <[EMAIL PROTECTED]> writes:
> > 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.
Anyone out there ever see military time zones being used? If support for
them has been removed, this ought to be clearly documented (e.g. in
ChangeLog and docs/DIFFERENCES).
> Seriously, though, I think having a handful of functions in this other
> subdirectory over here was confusing without any obvious benefits.
Yup. As soon as the new time parsing seems to be working as well as the old
version (modulo military time zones, perhaps), we ought to delete the
directory.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
