On Wed, Mar 13, 2019 at 4:05 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
