fix: parse an epoch timestamp of exactly zero

[VXNCXNX]

Fixes #1586.

The cause

The epoch parsers all end by reporting success based on the value rather than on whether they parsed anything:

return (epoch > 0);

So a timestamp of exactly 0 — the unix epoch itself — is indistinguishable from "no digits here", and lnav rejects the line. Your "Huh, that's an odd one... some sanity check somewhere" was on the money; the sanity check is the return statement itself.

The fix

Report success when digits were actually consumed:

return (off_inout > off_start);

off_start was already declared in ptime_s and ptime_q for their overflow guards; ptime_i, ptime_6 and ptime_9 needed it added. The existing epoch >= MAX_TIME_T range guards are untouched, and a field with no digits still fails because the loop consumes nothing.

%q is included. The issue is about %s, but ptime_q (hex epoch) has the identical return (epoch > 0) and therefore the identical bug — a hex epoch of 0 fails to parse for the same reason. Fixing four of five would have left the same defect in the codebase, so I did all five. Say the word if you'd rather it were scoped down.

Testing, and what I could not do

Being straight about this: I could not run make check. autoconf, automake, cmake and pkg-config are all absent from my environment — only g++ is available.

What I did instead was compile the real src/ptimec.hh and src/ptimec_rt.cc against the repo's own third-party/date headers, with small stubs for config.h, lnav_log.hh and the three out-of-line time helpers, and exercise the five functions directly:

                              patched      unpatched
ptime_s   "0"                 true  ok     false  FAIL
ptime_i   "0"                 true  ok     false  FAIL
ptime_6   "0"                 true  ok     false  FAIL
ptime_9   "0"                 true  ok     false  FAIL
ptime_q   "0"                 true  ok     false  FAIL
ptime_s   "x"                 false ok     false  ok
ptime_q   "z"                 false ok     false  ok
ptime_s   ""                  false ok     false  ok
ptime_s 1428721664            true  ok     true   ok
ptime_q hex 5527ad80          true  ok     true   ok

5 failures before, 0 after, with the non-digit and normal-value cases unchanged in both directions.

Test cases are added to test/test_date_time_scanner.cc in the existing style: one asserting all five conversions parse 0 to epoch zero, one asserting a digit-less field is still a failure. (x is not a hex digit, so it's a valid negative case for %q too — I checked.)

A NEWS.md entry is added under ## lnav v0.14.1.

The full doctest suite and any end-to-end log-file test remain unrun on my side.

Callers

ptime_fmt in src/ptimec_rt.cc is the only dispatcher and just propagates the boolean; its only in-tree consumer is src/log_format.cc:3993. date_time_scanner.cc has no zero-value special case. Nothing depended on 0-means-failure.