Travis Vitek wrote:
Travis Vitek wrote:
Travis Vitek wrote:
The problem is that some locales pad their date/time output with
whitespace [like '7. 6. 1988' or ' 7.6.1988'] and I'm unable to use
num_get<>::get_[time,date] to read what is written by
num_put<>::put. It
is my understanding that I should be able to do so. Is this a bug, a
known issue, or is it acceptable behavior that I need to code
around in
the test?
Whoops, obviously I am talking about the time_[get,put] facets here.
Okay, so I've done the required research. These are the relevant
sections of the standard that I was able to find.
[22.2.5.1 p1] Each get member parses a format as produced by a
corresponding format specifier to time_put<>::put. If the sequence
being parsed maches the correct format, the corresponding members of
the struct tm argument are set to the values used to produce the
sequence; otherwise either an error is reported or unspecified values
are assigned.
[22.2.5.1.2 p2] Effects: Reads characters starting at s until it has
extracted those struct tm members, and remaining format characters,
used by time_put<>::put to produce the format specified by 'X' or
until it encounters an error.
Unless I'm missing something obvious, it appears that the output of the
time_put<> facet is required to be parseable by the time_get<> facet.
Yes. But notice the text doesn't say anything about time_put_byname or
time_get_byname ;-) The C++ standard (or even the C standard for that
matter) isn't going to of help here.
Of
course that isn't what I'm seeing.
Test case?
One case that fails is the weekday '%e'. With some locales '%x' expands
out to '%m/%e/%Y'. Anyways, when putting the data,
__rw_get_time_put_data() correctly sets the field width to 2. When we
attempt to get the data back out of the stream, no width is specified.
There is no code in place in the get_date() call stack to deal with
width, and the block of code that does the actual parsing doesn't have
any concept of field width either [_time_get.cc:284].
It's hard to say from just looking at the code (and I haven't looked
very carefully). In general, we [try to] to implement the POSIX
semantics, so if it works with strptime()/strftime() it should work
with our time_put_byname/ time_get_byname.
Worse yet is that the tests actually verify this bad behavior. The
22.locale.time.get test verifies that the '%e' format fails if there is
any leading whitespace.
If we test this behavior it's gotta be right ;-) Where does POSIX
say leading spaces must be skipped? I see this under %e: Equivalent
to %d. And under %d: The day of the month [01,31]; leading zeros
are permitted but not required. Nothing about ignoring spaces.
// %e Equivalent to %d; leading zeros are permitted but not required.
STEP ("%e: equivalent to %d");
TEST (T (0, 0, 0, 1), "01", 2, "e", 0, Eof);
TEST (T (0, 0, 0, 9), "9", 1, "e", 0, Eof);
TEST (T (0, 0, 0, 31), "31", 2, "e", 0, Eof);
TEST (T (0, 0, 0, 0), "0", 1, "e", 0, Eof | Fail);
// leading whitespace not allowed
TEST (T (0, 0, 0, 0), " 2", 0, "e", 0, Fail); // *** problem
TEST (T (0, 0, 0, 0), "99", 2, "e", 0, Eof | Fail);
The 22.locale.time.put test verifies the leading space is there when
writing the '%e' format.
// %e: the day of the month as a decimal number (1-31);
// a single digit is preceded by a space. [tm_mday]
rw_info (0, 0, __LINE__, "%%e: the day of the month as a decimal
number");
TEST (T (), "%e", 0, 0, ' ', "%e");
TEST (T (), "%e", 0, 0, ' ', " 1"); // *** problem
TEST (T (), " 1", 0, 0, ' ', "%e"); // *** problem
TEST (T (-1), "%e", 0, 0, ' ', "%e");
Feedback?
Without too much research, my first take on this is that it will
probably fall under the "not every output format can be parsed"
category. But we need to do some more reading to confirm this
hypothesis.
Martin
