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

[enh]

On Tue, Aug 4, 2020 at 3:27 AM Rob Landley <rob at landley.net> wrote:
>
> 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.

d'oh, i forgot i was in lib/ and could use libbuf.

> (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)

that's for _output_ though. if you read the _info_ page where it talks
about input:

   The time may alternatively be followed by a time zone correction,
    expressed as ‘SHHMM’, where S is ‘+’ or ‘-’, HH is a number of zone
    hours and MM is a number of zone minutes.  The zone minutes term, MM,
    may be omitted, in which case the one- or two-digit correction is
    interpreted as a number of hours.  You can also separate HH from MM with
    a colon.  When a time zone correction is given this way, it forces
    interpretation of the time relative to Coordinated Universal Time (UTC),
    overriding any previous specification for the time zone or the local
    time zone.  For example, ‘+0530’ and ‘+05:30’ both stand for the time
    zone 5.5 hours ahead of UTC (e.g., India).  This is the best way to
    specify a time zone correction by fractional parts of an hour.  The
    maximum zone correction is 24 hours.

i deliberately didn't support the hour-only format because it seemed
like a footgun: "003" means "0003" rather than "0030", for example.
but i don't care strongly. we'll probably never have anyone use
anything other than HHMM or HH:MM in the wild anyway.

i've sent a patch adding the missing tests for the bit i didn't
support but you did. thanks!

> Because FSF.

yeah. see above :-)

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

i did mess around on the command line before thinking "i bet info has
stuff man doesn't", and didn't manage to find any such syntax
experimentally either. (nor, from my previous life as Android's tzdata
maintainer, do i remember any such thing. quarter-hour offsets are as
weird as i've ever seen.)

> > 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.

(stupidly, i noticed that early on but forgot to come back and fix it.)

> 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.

yeah, personally i always use the +HHMM form. which is odd, because
i'm usually such a stickler for ISO 8601. oh, it's _optional_ in ISO
8601, but required in RFC3339.

> 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.

lgtm, thanks!

> Thanks,
>
> Rob