[Toybox] [PATCH] xparsedate: support UTC offsets.

[Rob Landley]

On 8/3/20 7:07 PM, enh via Toybox wrote:
> Requested in https://github.com/landley/toybox/issues/130, quoting an
> old version of the toybox help.

The magic tz[10] length is ok within a function, but passing a buffer you write
to with no length across function calls makes me uneasy.

(Yes, that includes "scratch" in scan_key_getsize(), but at least using the
first byte as the offset caps it at 256.)

> This is also supported by coreutils.

Where "supported" says in the date man page:

       %z     +hhmm numeric time zone (e.g., -0400)

       %:z    +hh:mm numeric time zone (e.g., -04:00)

       %::z   +hh:mm:ss numeric time zone (e.g., -04:00:00)

       %:::z  numeric  time  zone  with  :  to necessary precision (e.g., -04,
              +05:30)

Because FSF. IS there a time zone with seconds?
https://www.epochconverter.com/timezones doesn't list any but why should that
stop the FSF?

> Set $LANG to C in the date tests so that they pass with TEST_HOST=1
> (they were already failing for me, presumably related to a newer glibc).

You're setting oldtz multiple times, and the second time through the loop would
overwriting the old value with the new one you set it to last time.

Do you mean to support HHMM without a colon between them? Is this a requirement?
Comment at the top doesn't seem to think so. In fact comment says "Turn a
timezone specified as +HH[:MM] or Z into a value for $TZ." but the code fails if
[MM] isn't there (second sscanf returns 0)...

Ah, the help stanza you added has an example without the : so yes, that's
intentional. Darn it, if (sscanf(++p, "%2u%n:%2u%n", &h_off, &len, &m_off,
&len)<1) return 0; was elegant-ish. Oh well.

Ok, fixed that up moved it inline and shrunk it by 10 lines, result passes make
test_date, Let me know if I broke it.

Thanks,

Rob