aboutsummaryrefslogtreecommitdiff
path: root/tests/date.test
AgeCommit message (Collapse)Author
2019-03-14date: don't hard-code 2019 in the test.Elliott Hughes
I'm not worried about hard-coding the *century* in the other test. We'll be long dead before that's an issue, and it's easier to read this way.
2019-03-13date: fix various time zone/daylight time issues.Elliott Hughes
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. The majority of this patch implements what I'd been unsuccessfully trying to explain on the list: that to correctly implement the distinct input and output time zones (as demonstrated in the three failing tests we've been carrying around for a while), we should switch to working with time_t internally rather than struct tm. I've also added the code to temporarily switch to the input time zone (and back again). All the tests now pass.
2019-02-13date: more test cleanup.Elliott Hughes
Add the SKIP_HOST=1 for the POSIX inputs to -d that coreutils doesn't support. 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.) Also rename the tests to make it clearer that these are all POSIX format.
2019-02-11date: some fixes.Elliott Hughes
Add support for more input formats, primarily the ISO formats used by the AOSP build. I've improved/added to the tests a bit to cover these changes, and to explain the reasons for the various remaining test failures (none of which are regressions caused by this patch).
2018-10-06date.test: add some tests.Elliott Hughes
These are reasonable examples I found in AOSP. I also came across "today" (which is the same as the more obvious "now"), "yesterday", "7 days ago" and "1 month ago". I'm not sure how far down that rabbit hole we want to go. But these ones at least seem reasonable.
2017-05-19Implement date %N, loosely inspired by Elliott Hughes's patch.Rob Landley
I didn't implement %37N's ability to insert zeroes, so removed those two tests. If you really need it, I can add the divide loop back.
2017-03-28New date range tests are simple, won't catch Feb 29 in non-leap-yearRob Landley
(or April 31 in any year). Some normalization allowed, exclusions are just what http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html says.
2016-07-04Fix chattr and date tests.Rob Landley
2016-03-02Factor out command name at the start of test name, have runtest.sh print it.Rob Landley
2015-11-12Fix year parsing in date(1).Elliott Hughes
Four-digit years were being mangled by the code for two-digit years. Move all the two-digit year code into the "we only saw two digits" case. Add some new tests and fix existing tests.
2015-08-11Fix more date bugs.Elliott Hughes
Correctly and portably check for non-normal dates, and explicitly show the "before" and "after" dates (in the format of the user's choosing). Clear the struct tm in date_main rather than parse_default because on one path the struct tm is actually initialized. Explicitly clear the tm_sec field in parse_default because -- experiment shows -- that should not be preserved. Only do the "what does this 2-digit year mean?" dance if we actually parsed a 2-digit year. Show the right string in the error message if strptime fails. Also add more tests, and use UTC in the tests to avoid flakiness.
2015-08-08Reject invalid dates in date(1).Elliott Hughes
Humans get upset when date(1) lets mktime(3) work out what the 99th day of the 99th month would be rather than rejecting the invalid date. For the subtly wrong cases, rather than get into the leap year business, let's rely on localtime_r(3).