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

[enh]

On Wed, Feb 13, 2019 at 5:07 AM Rob Landley <rob at landley.net> wrote:
>
> 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?

mostly. personally i think unix and ISO are both reasonable, but that
in general any format that elides _larger_ stuff than you've already
given should just be rejected (and eliding anything _smaller_ gets you
zeros). so folks saying 2019-02-13 getting the other fields zeroed
sgtm, but i'd just say "no" to 02-13 or equivalents. i'm maybe
sympathetic to accepting "09:15" meaning "just leave the date alone",
but honestly think even that will probably cause more harm over its
lifetime than the good it will do.

(i was pleased to see that the AOSP build only uses unix and ISO. and
of course we're obliged to support POSIX, even if it does have the
weird [[CC]YY] behavior. and is little-endian.)

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

the BSDs have _tz variants, but iirc they're subtly different because
that's what BSD does best.