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:
|