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

[Rob Landley]

On 2/13/19 12:29 PM, enh wrote:
> 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) :-)

$ date --date=1:2:3
Wed Feb 13 01:02:03 CST 2019
$ date --date=98-7-6
Mon Jul  6 00:00:00 CDT 1998

They appear to be there in ubuntu. And yes, their behavior is inconsistent.
*shrug* I'd go with the ! thing, it's easy enough to implement...

>> P.S. 0x2b|!0x2b==0xff

Hang on, this is gonna break in 10 months:

    // 2 digit years, next 50 years are "future", last 50 years are "past".
    // A "future" date in past is a century ahead.
    // A non-future date in the future is a century behind.
    if (len == 2) {
      unsigned r1 = tm->tm_year % 100, r2 = (tm->tm_year + 50) % 100,
        century = tm->tm_year - r1;

If 12-31-69 (or 1-1-70) is not the Unix epoch, something somewhere is going to
be sad. (And one of those things might be patch files that use a date stamp of
the unix epoch to incidate file did not exist and we're creating/deleting it.
These days we compare with /dev/null and I think there's a newer git delete
syntax that doesn't require you to state the contents of the file being deleted
(is it just a mv to /dev/null?), but still...)

Hmmm... I can hack it so it's 60 years back and 40 years forward, or even 80/20,
but this is one of them "not quite y2038" things that's not gracefully solveable
without making an old assumption in other people's code go away? Hmmm. I know 51
years from now, 1-1-70 ain't gonna mean "1970"...

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

Could you give me a command line example of this? I'm not getting it to work here...

>> (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'm all for ripping it out...

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

Alas, old Android builds use old toybox versions because the build's a giant
hairball. I can see a new toybox being built on Ubuntu 14.04 (and in fact I'm
doing that), but a new toybox being retroactively inserted into a 5 year old
version of AOSP seems unlikely.

Going forward I'd _like_ to decouple this so Android provides a generic native
build environment you can grab new package versions and build under. In fact
that's explicitly what I'm working towards. But for the moment, we're not there
yet, so the build environments we have to support are

That said, a static toybox binary being dropped into an older Android system may
be an interesting use case and the 7 year support horizon may currently apply to
_that_, but presumably "fixed in bionic" means the static bionic it's linked
against wouldn't need tzset()...

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

Exactly. :)

Rob