Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0339 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 0339.

Report 0339 Actions

    Problem Report Number 0339
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0055
    Raised 1996-01-09 08:00
    Updated 2003-03-13 08:00
    Published 1996-02-09 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.3.5
    Test Identification XPG4.os/time/strptime 3
    Specification System Interfaces and Headers Issue 4
    Location in Spec See Problem Text
    Problem Summary PIN4.055 The three failures are different instances of two cases: strptime("0091", "%y", &testbuf); strptime("00", "%w", &testbuf); The failure occurs when strptime tries to convert a a string with leading zer...
    Problem Text

    The three failures are different instances of two cases:

    strptime("0091", "%y", &testbuf);
    strptime("00", "%w", &testbuf);

    The failure occurs when strptime tries to convert a a string with leading
    zeros that make the string longer than its expected length, where the
    "expected" length is the length of the corresponding string returned by
    strftime(). We consider such strings to be invalid data, and results based
    on such data to be undefined.

    In the first two failure cases, our implementation sets the
    year-of-century to 00 and returns a NULL pointer when it
    fails to set day-of-the-week to 9.

    In the last failure, the year-of-the-century is set to zero. The standard
    does not specify the value of the century set by the %y directive.
    We chose to make the century consistent with its usage in mktime(),
    and by the touch utility. The century for %y from 69-99 is 19. The
    century for %y from 20 to 38 is 20. The tm_year value of 100 = 2000 -
    1900 is correct.

    >From XSH4 version 2, pp. 614 ff.:

    %w is the weekday as a decimal number [0,6], with 0 representing
    Sunday; leading zeroes are permitted but not required.
    %y is the year within the century [0,99]; leading zeroes are
    permitted but not required.

    (Same for other numeric conversion specifications.)

    In either case, the number of leading zeroes allowed is not specified.
    The size of the data field, however, is implicitly specified in each case:
    one digit for %w; two for %y.

    We believe that the purpose of the optional leading zeroes is to make
    strptime() more precisely complementary to strftime(): "in order to
    ease the use of identical format strings for strftime() and strptime()"
    (XSH4 version 2, p.616, Application Usage.) We also cite PIN4.037,
    which was also based on the need for symmetry between the interfaces.

    Applications using strftime() and strptime() have historically used a
    common data format for both. Although the interpretation of the handling
    of leading zeros in the specification is ambiguous, a change in our
    implementation to match the interpretation used by the test suite might
    endanger those applications.
    Test Output

    /tset/XPG4.os/time/strptime/T.strptime 3 Failed

    Test Description:
    If strptime() is supported:
    When format is a string made up of a series of the following field
    descriptors :
    ...
    n. w day of week - 0 to 6 (Sunday = 0) (with or without leading
    zeros)
    ...
    p. y last two digits of year - 00 to 99 (with or without leading
    zeros)
    ...
    then a call to strptime() reads characters from string and, in the
    case that these characters match the format of the directive,
    translates these characters into the appropriate member of the tm
    structure. Occurrences of "%%" in the format string are matched
    against a single "%" and do not affect the tm structure.
    ...
    strptime("0091 00 01", "%y %w %U", &testbuf) failed.
    return value was NULL
    weekday , two digit year, and week number of the year, with leading
    zeroes
    strptime("0091 00 01", "%y %w %W", &testbuf) failed.
    return value was NULL
    last two digits of year with leading zeroes
    strptime("0091", "%y", &testbuf) failed.
    tm_year = 100, expected 91



    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The submitter's interpretation of the phrase "leading zeros are permitted but
    not required" in respect of the %w field suggests that leading zeros are
    not permitted. This is a single character field with valid characters in
    the range [0,6] and if the value is 0, then the 0 must be present since at
    least one character is required. This suggests that the comment about the
    leading zeros must apply to additional zeros appearing before the required
    single character. This leads to the conclusion that such initial zeros are
    allowable and should be correctly parsed by the call to strptime(), or that
    the specification is erroneous in stating that leading zeros are permitted.

    It is not clear how the fact that "leading zeros are permitted but not
    required" makes the %w formatting directive in strptime() more complimentary
    to strftime(), since strftime() will only produce a single character in the
    range [0,6] from the %w directive. Neither is it clear how the requirement
    that leading zeros are permitted changes the symmetry between strftime() and
    strptime(). A string generated by strftime() when passed to strptime()
    should still produce the same struct tm as that originaly passed to
    strftime(). However, a string which is correctly parsed by strptime() to
    produce a struct tm will not necessarily produce the same string when the
    resulting struct tm is passed to strftime(). This occurs because
    strptime() does not require leading zeros to be present when some of the
    format specifiers (including %y) are used, and strftime() always outputs
    leading zeros to produce a consistent field length. For example, in the C
    locale, a call to strptime("7","%y",tm) followed by a call to
    strftime(buf,3,"%y",tm) will yield the string "07" rather than the "7"
    passed to strptime().

    It is also difficult to understand how a change in the handling of the
    leading zeros would endanger applications, unless the applications were
    relying on the fact that leading zeros would not be discarded during parsing.
    This seems to be a strange behavior for the application to rely on, and it
    is doubtful that such an application would be portable to other X/Open
    compliant implementations.

    It is not recommended that a waiver is granted, though it is recognised that
    there is some ambiguity in the statement that "leading zeros are permitted
    but not required" and this may be worthy of review by the K/RT working group.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority