[Toybox] [PATCH] date: some fixes.

[Rob Landley]

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.

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

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

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

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