Martin Sebor wrote:
>
>Travis Vitek (JIRA) wrote:
>>
>> Well, most of these failures are destined to fail until the
>test is rewritten.
>
>Are you sure you meant that the test needs to be rewritten?
>(I'm trying to reconcile that with your subsequent comment
>about binary compatibility).
The entire test doesn't need to be rewritten, just the assertions that
deal with %U and %W...
TEST (T (0, 0, 0, 0, 0, 320, 2, 60), "9", 1, "U", 0, Eof);
Even if I had a perfect implementation (i.e. I called the gnu strptime
function internally), the first assertion could never be made to pass.
Given a Sunday-based week number of 9, I cannot possibly guess the year,
weekday and day of year to be 2220 AD, Tuesday and 60 respectively. The
assertion is bad. This assertion needs to be updated or removed
entirely. At the very least the expected date should be all zeros as the
below testcase does.
TEST (T (0, 0, 0, 0, 0, 0, 0), "0", 1, "W", 0, Eof);
I modify time_get<>::do_get() to consume and ignore characters that
match "%U" and "%W" from the stream. This would get the assertion to
pass, but it wouldn't be incredibly useful.
>
>> It is impossible to reliably parse any useful date-time
>information from a string that contains only the formatted
>week number.
Just a note; the gnu strptime() succeeds if parsing only the week
number, but it doesn't modify the date. On solaris, that same call seems
to fail if it encounters the %U or %W specifier in the format string,
even if that string contains a fully formatted date.
>The test tries to to do just this for {{%U}} and
>{{%W}}.
I'm not exactly sure what the expected behavior should be, given the
above results on linux and solaris. Perhaps parsing the values and not
using them is sufficient, or just failing outright when reading them (as
it does now). Regardless of what we decide,
>Even if we have a partially specified date (I believe
>we need at least the year and day of week), we still need
>somewhere to store the additional data so that we can store
>the value we parse, and then after the parsing is done so that
>we can use it to calculate something useful. At the very least
>I think we'll be breaking binary compatibility.
>>
>> So, for the time being, I think the right thing to do is to
>fix the portion of the test that attempts to to verify {{%U}}
>and {{%W}} so that it expects failure.
As mentioned above...
>If we wish to fully
>support this extension, then we should add a new test that
>verifies {{%U}} and {{%W}} with the necessary format
>specifiers and then fix the code for 4.3 or later.
>>
The test would need include something like this. As mentioned in my
previous post, I think we would need to break binary compatibility to
even have a chance of making these pass.
// expect 2008-12-29 given "2009-W01-1"
TEST (T (0, 0, 0, 29, 12, 28, 1, 363), "2009-W01-1", 1, "%Y-W%W-%d",
0, Eof);
// expect 2010-01-03 given "2009-W53-7"
TEST (T (0, 0, 0, 3, 1, 30, 3, 3), "2009-W53-7", 1, "%Y-W%W-%d",
0, Eof);
Travis
