Parse Library Fixes Timezone Pattern Bugs on Master

The parse library is the small Python package that turns log lines into structured data with a single parse() call. Four commits landed on master in the last week, and one of them fixes a real correctness bug: any format using %z was reading values from the wrong match groups for every field after it.

The most recent commit fixes issue 262. When the parser expands a {:...} datetime directive, it builds a regex from dt_format_to_regex. The %z entry generated two optional capture groups of its own, but the field counter never counted them. Fields after a %z field were then read from the wrong match groups.

Concretely, parse("{:%Y-%m-%d %H:%M:%S%z}|{}", "2020-03-04 05:06:07+0200|abc") returned garbage for the second field. The fix adds one line in Parser._handle_types:

self._group_index += re.compile(s).groups

The generated pattern itself was tidied in the same commit. The old %z regex had (:?[0-9]{2})?, which created capture groups even when not matching. It is now (?::?[0-9]{2})?, a non capturing group. Tests in tests/test_parse.py cover both positional and named fields after a %z field, including span checks.

If you parse log lines with timestamps plus trailing fields, this is the change worth pulling. It is a silent data corruption class of bug, not a crash.

A second timezone related change landed earlier. The Reject out-of-range timezone minutes commit makes the FixedTzOffset conversion reject timezone strings with minutes above 59. Previously +0599 parsed fine and produced a bogus offset. The regex accepts any two digits, so validation has to happen at conversion time.

This matters less for correctness and more for data quality. Garbage timestamps that previously slipped through now fail loudly at parse time. If you relied on lenient behavior, that is gone, but nothing legitimate broke.

The third fix targets strf_date_convert. Under case insensitive matching, am, pm, and Z (Zulu) conversions ignored the case flag and rejected lowercase input like 5:06pm. The commit from simpleqt makes these conversions respect the parser case setting.

Note the tradeoff: if you previously used case insensitive matching and your data contained only uppercase AM, that still works. The fix widens what is accepted, it does not reject prior valid input.

The remaining commit is docs only. The README update explains how extra_types maps strings to your own conversion callables. Useful if you have ever been surprised that a registered type receives the raw matched string rather than anything pre converted. No code changes.

  • The %z fix changes group bookkeeping for every datetime directive path. If you maintain a fork or a patched parser, port this change and the cleaned regex together.
  • Expect more timezone validation follow ups. The regex for %z still accepts shapes like +05 with no minutes, so there is room for another tightening pass in parse/init.py.
  • Activity is modest, four commits and 67 insertions, but the repo is clearly getting real world bug reports again. Watch the issue tracker for more group counting edge cases in formats with multiple datetime fields.