[Toybox] [PATCH] date: some fixes.

[enh]

On Mon, Feb 11, 2019 at 10:39 PM Rob Landley <rob at landley.net> wrote:
>
> On 2/12/19 12:05 AM, enh wrote:
> >> Huh, 4 of your new tests are failing with TEST_HOST=1 ?
> >
> > man, you really *never* read my comments in tests, do you? :-P
>
> Sorry, I had a long day at work and am trying to catch up on stuff with the
> dregs of my attention...
>
> >> FAIL: date -d 06021234
> >> FAIL: date -d 060212341982
> >
> > these are actually your tests, but moved around and commented to
> > explain why they fail on the host :-)
> >
> > ...i did want to talk to you about them, but i thought (correctly, as
> > it turned out) that the two timezones issue was going to be confusing
> > enough to be getting on with. but i did explain these failures in new
> > test comments:
> >
> > # TODO: these are rejected by coreutils and interpreted differently by busybox.
> > # busybox thinks this should use the current year, not 1900.
> > testing "-d 06021234" "TZ=$tz date -d 06021234 2>&1" "Sun Jun 2
> > 12:34:00 UTC 1900\n" "" ""
> > # busybox thinks this is the year 603 (ISO time 0602-12-34 19:82 with
> > out of range fields normalized).
> > testing "-d 060212341982" "TZ=$tz date -d 060212341982 2>&1" "Sun Jun
> > 2 12:34:00 UTC 1982\n" "" ""
> >
> > fwiw, i think we should reject this format [that i've never seen
> > before], just like coreutils does. but if you added this because
> > busybox added it because it is actually useful somewhere, then we
> > should probably be consistent with busybox (except busybox appears to
> > be insane, even if they're the only other tool i know that supports
> > this at all)! remove?
>
> It's posix:
>
>   http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html
>
>   date [-u] mmddhhmm[[cc]yy][Option End]
>
> mmddhhmm is 8 digits. The cc and yy are optional.

d'oh. as i say in the new patch i just sent, i was confused by the
fact that busybox does accept them but interprets them differently.
(one worse, one better, imho.)

i've renamed the tests to make it clear what format they are, and...

> >> FAIL: date -d 1110143115.30
> >> FAIL: date -d 111014312015.30
> >
> > these are a bit different. again, coreutils rejects these, but i
> > totally understand why toybox supports them (because they're the usual
> > POSIX date *setting* format), and toybox's interpretation of these is
> > logically consistent with POSIX. i just didn't know how to say "skip
> > these two on the host because ...".
>
> SKIP_HOST=1 (grep for SKIP_HOST in tests/*.test for examples).

...added the missing `SKIP_HOST=1`s because of coreutils.

> Of course what that should probably do is skip when the host version isn't
> toybox, which isn't what it's currently testing. (Or run the test but turn FAIL
> into SKIP? It would be nice to have more cycles to put into the test suite but
> it's after midnight and I'm falling over...)

(yeah, when i'm testing manually i often test coreutils, busybox, and
toybox, and it would sometimes be useful to be to able to express that
in the checked-in tests.)

> >> They SAY the epoch is in UTC and this is seconds since that! Right there in the
> >> man page! They're inconsistent with their own man page!
> >
> > i don't think they are. i think you just have to read the whole man
> > page and realize that although they treat this as UTC on the way in,
> > they'll convert it to $TZ on the way out. and my hack says "in the
> > absence of two conversions, take $TZ into account in the one
> > conversion we do do". so, yeah, gross, but a local maximum and "better
> > than busybox".
>
> Then why doesn't %s on output care what TZ says? (date +%s is output...?)

dunno. a special case on top of the special case? i'll have a poke at
that next time i have some time. at least add some more tests!

> >> But I don't think I currently understand the expected behavior...
> >>
> >> $ date ; date --date=@$(TZ=UTC date +%s)
> >> Mon Feb 11 23:33:58 CST 2019
> >> Mon Feb 11 23:33:58 CST 2019
> >> $ date ; TZ=UTC date --date=@$(date +%s)
> >> Mon Feb 11 23:34:15 CST 2019
> >> Tue Feb 12 05:34:15 UTC 2019
> >>
> >> No, I _really_ don't understand what's going on here.
>
> So... date +%s is printing UTC (regardless of what TZ says), then --date=@ is
> inputting UTC but then printing the current time in $TZ...
>
>   $ date +%s; date --date=@$(date +%s) +%s
>   1549953350
>   1549953350
>
> Ok. That almost makes sense, I think? So maybe the localtime_r is right.
>
> So... what does specifying TZ in the format do differently? (I can probably
> figure this out on my own when I'm not falling asleep...)
>
> Rob
>
> P.S. Zzzzzzzz...