aboutsummaryrefslogtreecommitdiff
path: root/tests/date.test
AgeCommit message (Collapse)Author
2020-11-15date: add --iso and the %:z output format.Elliott Hughes
I didn't know until implementing this that --iso is actually called --iso-8601 and that GNU date will actually accept any prefix. --iso-8 works fine too. I've assumed that --iso (that I always used) and --iso-8601 (as given in the documentation) are the only two that matter.
2020-08-27xparsedate: support default date(1) output format.Elliott Hughes
This round trip occurs in practice with $KBUILD_BUILD_TIMESTAMP in kernel builds.
2020-08-04date.test: add more UTC offset tests.Elliott Hughes
Rob's code supports more formats than mine did, so add the extra tests.
2020-08-04xparsedate: support UTC offsets.Elliott Hughes
Requested in https://github.com/landley/toybox/issues/130, quoting an old version of the toybox help. This is also supported by coreutils. Set $LANG to C in the date tests so that they pass with TEST_HOST=1 (they were already failing for me, presumably related to a newer glibc).
2020-01-06date.test: defuse a time bomb.Elliott Hughes
One of these tests fails in the gap between the locale it's run in changing the year and Europe/Berlin's changeover (caught by our automated testing, which tends to celebrate every new year by finding mistakes in tests like this). Another test has been failing consistently since 2020 because the default date output format includes the day of the week. Rather than implement Zeller's Congruence in the shell, explicitly use a format that doesn't include the day of the week for that test (and reuse the now-fixed calculation of the current year used by the other year-sensitive test).
2019-04-22Switch some SKIP_HOST tests to toyonly. (The host could be toybox.)Rob Landley
2019-03-26Make touch use xparsedate() (result: -t and -d the same, autodetects format),Rob Landley
and fix tests to pass on host too.
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).