| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
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.
|
|
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).
|
|
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.
|
|
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.
|
|
(or April 31 in any year). Some normalization allowed, exclusions are just
what http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html says.
|
|
|
|
|
|
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.
|
|
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.
|
|
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).
|
