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

[enh]

On Wed, Feb 13, 2019 at 10:14 AM Rob Landley <rob at landley.net> wrote:
>
> On 2/13/19 11:18 AM, enh wrote:
> >> 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.
>
> Which means your array of accepted formats needs a "to blank nor not to blank"
> field, which could just be an initial ! character or something.

or we remove the last two entries, which i have no use for and
probably shouldn't have added (but they're in `busybox date --help`
and not obviously terrible, other than this issue) :-)

> P.S. 0x2b|!0x2b==0xff
>
> > (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.)
>
> But the build uses the TZ stuff?

yes. specifically for stuff like `TZ="UTC" 2019-02-13`.

> >> 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.
>
> I continue to plead the third.
>
> (Why are we calling tzset() again? What's the point?)

hysterical raisins^W^Whistorical reasons. afaik, you don't need that
on any *current* OS. but historically that line in the (localtime
docs)[http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html]
about "as though localtime() calls tzset()" wasn't there, so to be
safe you call tzset(3) manually.

i don't remember exactly when Android and iOS fixed this, but i'm
pretty sure it was in the last 7 years. (and i do remember that we
fixed it because someone had code that relied on it and it was working
everywhere else at that point.)

but since _i_ only care about current Android (and you probably only
care about old Android with a static libc anyway, because good luck
trying to get toybox to build on old Android), i think we can rip all
the tzset()s out.

> Rob