[Toybox] [PATCH] date: fix various time zone/daylight time issues.

[enh]

On Wed, Mar 13, 2019 at 4:05 PM Rob Landley <rob at landley.net> wrote:
>
> On 3/12/19 8:09 PM, enh via Toybox wrote:
> > Sunday's transition in the US broke a bunch of the tests. Worse, it
> > broke some of the QA folks' scripts. Finally, the boil that is date's
> > handling of time zones and daylight time has come to a head...
> >
> > This patch fixes the newly-failing tests *and* the other tests that were
> > checked in failing to serve as TODOs.
> >
> > I've resolved the test TODOs about whether implied year/century in POSIX
> > format should mean the current year or 1900 in favor of the current
> > year. Both busybox and coreutils agree, and Rob fixed the code recently
> > so toybox agrees too, but without fixing the tests.
> >
> > I've switched tests from Europe/London to Europe/Berlin to avoid
> > disagreements between C libraries about whether to say "GMT" or "UTC"
> > when daylight savings is not in force.
>
> My own efforts in that area were:
>
> -# makes mistakes harder to spot.
> -tz=Europe/London
> +# makes mistakes harder to spot. Pick one with no Daylight Savings Time
> +# to avoid dealing with BST (British Summer Time) and friends.
> +TZD="TZ=US/Arizona date"

yeah, i'd strongly recommend against that... using a time zone with
DST is definitely a feature when testing this kind of code.
Europe/London is just awkward because of UTC/GMT naming.

the tests didn't help in this particular case because it wasn't the
*input* time that was the problem --- it was the system time. the code
to copy the current century/year for cases with implicit century/year
was also copying the "dst-ness" from the current system time.

ideally we'd also run all date-related tests not only with dst/std
inputs but also while with dst/std current times. that might work for
your qemu plans where you can just change the system clock, but in the
absence of a clone(2) option that lets us have a new time namespace,
i'm not sure what i could write that i could actually run.

(the other issue that hurt us here, that even more so wasn't something
we can fix in the toybox tests themselves is that Android doesn't
currently have any infrastructure for running shell script tests. the
test folks are working on it now, and i hope to be able to get the
toybox tests in as soon as there's something available.)

((speaking of which, some of the tar tests are failing now.))

> And stuff like:
>
> +# Test is racy if run just beore midnight, especially on new year's
> +SKIP_HOST=1 testing "-d MMDDhhmm" "$TZD -d 06021234 2>&1" \
> +  "$(date +%a) Jun  2 12:34:00 UTC $(date +%Y)\n" "" ""

yeah, i have a TODO to fix the hard-coded years, but it was exactly
this issue that's so far prevented me from doing so. but that's silly.
"the perfect is the enemy of the good". i'll at least send this part
now.

(funnily enough, back when i was responsible for the time
zone/calendar stuff in the java libraries, we actually did see these
kinds of "crossing midnight at the end of a month" failures. data
centers don't sleep.)

> That said you've put more thought into this than I have and have more people
> <strike>yelling at you</strike> presenting test data, so I've applied this patch
> as-is and I can head-scratch over it later. (Trying to finish the tar cleanup...)

in a way i was quite glad to have this because i've wanted to fix that
whole "two zones" thing for a while but never had the time to sit down
and think about nothing else.

i haven't forgotten the tzset cleanup either. i'll try to get to that
this weekend too. (your time is better spent on things like tar and
dd.)

> Rob