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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1016 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 1016.

Report 1016 Actions

    Problem Report Number 1016
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0116
    Raised 2001-01-09 08:00
    Updated 2003-03-13 08:00
    Published 2001-02-16 08:00
    Product Standard Commands and Utilities V3 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSC version 5.1.2
    Test Identification XOPEN.cmd/get 1081,1084
    Specification Commands and Utilities Issue 5
    Location in Spec See Problem Text
    Problem Summary PIN4C.00052 This IR identifies a grey area in XCU5 relating to leading zeros in the date fields of expanded SCCS keywords
    Problem Text

    The VSC test assertions 1081 and 1084 for the 'get' command have
    historically checked for dates which stripped the leading zero
    from the month and date field and considered these to be allowable.
    For example, for the date Jan 04 2000 the value returned by 'get' command
    will be "1/4/00" and is compared with either "01/04/00" or "1/4/00" by the
    test suite. The tests used to pass. Also, this is consistent with a number
    of implementations and with traditional behavior.

    Beginning with dates in 2001 however, these test assertions will now fail
    because of an error in the testsuite.

    The test output for assertion 1081:

    520|1 1 8958 1 1|Assertion #1081 (C): substitution of %\\H% keyword
    520|1 1 8958 1 11|Command failed: '[ "1/4/01" = "01/04/01" ]["1/4/01" = "1
    520|1 1 8958 1 12| <LC> /4/1" ]'
    220|1 1 1 15:06:11|FAIL

    For the example date of Jan 04 2001 the test fails because the value returned
    by 'get' command "1/4/01" is compared with either "01/04/01" or "1/4/1" by the
    test suite.

    The existing specifications for 'get' does not mention that
    stripping leading zeros from the month and day field when using
    the %H% and/or %G% identification keywords is an allowable
    alternative. This would appear to be an unintentional omission from the
    specification and should be clarified to allow the VSC test assertions
    to be corrected.

    A permanent interpretation and PIN # are being requested to note
    that it is acceptable for implementations to strip leading zeros from
    the month and day fields of the dates substituted for the %H% and %G%
    identification.

    Test Output
    Asser#1081:
    ---------
    520|1 1 8958 1 1|Assertion #1081 (C): substitution of %\\H% keyword
    520|1 1 8958 1 11|Command failed: '[ "1/4/01" = "01/04/01" ][
    "1/4/01" = "1
    520|1 1 8958 1 12| <LC> /4/1" ]'
    220|1 1 1 15:06:11|FAIL


    Asser#1084:
    ---------
    520|4 1 9175 1 1|Assertion #1084 (C): substitution of %\\G% keyword
    520|4 1 9175 1 11|Command failed: '[ "1/4/01" = "01/04/01" ][
    "1/4/01" = "1
    520|4 1 9175 1 12| <LC> /4/1" ]'
    220|4 1 1 15:06:20|FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    These test failures bring to light an issue with the XCU specification
    that has existed for many years. It has not been noticed before
    because the test suite has (until this year) given pass results for
    two different behaviours.

    The date format indicated for the %G% and %H% expansions in the
    description of the "get" command is MM/DD/YY. Historically some
    implementations have omitted leading zeros from the MM and DD fields.
    If the intention was for the specification to allow this behaviour,
    then this would have had to be explicitly stated (in order to allow
    it only for the MM and DD fields of the date, not for the YY field
    nor for the fields of the HH:MM:SS time format).

    The omission of such a statement may well have been unintentional.
    If this is the case, it needs to be confirmed by the Base Working
    Group, because the specification as written clearly requires two
    digit fields in all the date and time formats.

    It is recommended that this request is sent for 14 day review.

    Note: although this request only applies to the %G% and %H%
    expansions, the group may also wish to consider whether
    implementations should be allowed to omit leading zeros from the
    MM and DD fields of the YY/MM/DD format specified for %D% and %E%.
    (Apparently the submitter's implementation does not do so.) Then
    if a future interpretation request is received related to these
    formats it will not be necessary to send it for review.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request is being sent for a 14 day anonymous review.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This is a grey area in the specification and a Permanent Interpretation
    should be granted.

    The rationale is below:

    Even though the specification would indeed imply a 2 digit representation
    of day, month, year (and even second, minute, hour). There would
    not appear to be any text that explicitly disallows single digit
    representation. Indeed if you look at the -c cutoff option of the get
    utility on page 373 of XCU5 it indicates that cutoff date is 2 digit but
    then gives examples in 2 digit format (-c 750228235959) and in a mixed
    2 and single digit format (-c "77/2/2 9:22:25"). This text appears the
    same back to XPG2 which was where "get" was introduced.

    Given that until recently tests have passed with a variety of formats
    we could understand that existing implementations may vary on their
    interpretation of the specification and we would not want to break them
    in this area unless there is a pressing compatibility need. We don't
    see one at this time.


    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