[Toybox] [PATCH] date: more test cleanup.

[Rob Landley]

On 2/13/19 6:11 AM, Rob Landley wrote:
>> Fix some comments now Rob's pointed out that the "weird" format was just
>> POSIX with implicit CCYY or CC. (I was confused because coreutils rejects
>> them [as it rejects all POSIX input to -d], but busybox does accept them,
>> but interprets them differently, as explained in the test comments.)
> 
> Hmmm... busybox is probably right that it should use the current year.

Which raises the question of whether the struct tm should be intialized to
localtime() instead of memset to zero, but the _problem_ is that +FORMAT is for
the output format, not how to parse --date.

In fact there's no gnu/dammit way to specify a format to parse --date that I've
ever found (it just pachinkoes over the heuristics). An original busybox
extension (-D) was added on my watch back in he day:

  http://lists.busybox.net/pipermail/busybox/2006-February/018203.html

But the gnu/dammit guys never copied it because Not Invented Here I suppose. And
Jorg Schilling's not dead yet so I haven't submitted it to Posix, and it's not
like they'd ever notice on their own...

So figuring out what the _correct_ behavior is here is uncharted territory. But
I _suspect_ it's "initialize fields with current time, then write supplied
fields over them"?

If you want a cannonical way to record an instant in time, it's unixtime (with
fractional part). For all the rest of it, "January 3rd" generally means this
year. "The third" means this month...

Seem reasonable?

Rob

PS. I can understand having localtime() and gmtime() pay attention to an
environment variable for historical reasons, but when you make an _r version and
DON'T pass the timezone as an argument what is WRONG with you? Answer: the FSF
is what's wrong with you... Grrr, funky side channel signaling via global state...