 Relationships |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
| Anonymous | Login | 2022-05-28 13:06 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Type | Date Submitted | Last Update | ||
| 0000466 | [1003.1(2008)/Issue 7] Shell and Utilities | Editorial | Error | 2011-06-24 21:07 | 2020-03-05 15:04 | ||
| Reporter | eblake | View Status | public | ||||
| Assigned To | ajosey | ||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Applied | ||||||
| Name | Eric Blake | ||||||
| Organization | Red Hat | ||||||
| User Reference | ebb.date | ||||||
| Section | date | ||||||
| Page Number | 2575 | ||||||
| Line Number | 82887 | ||||||
| Interp Status | --- | ||||||
| Final Accepted Text | See Note: 0000966 | ||||||
| Summary | 0000466: date +%C problem | ||||||
| Description |
On the date page, it states that %C is in the bound [00,99], but this is untrue for the year 10000, and needlessly differs from strftime(). Additionally, 0000047 would have been prevented, and 0000169 would be simplified, if we were to keep date and strftime in lockstep by defining date in terms of strftime. Option 1 corrects the editorial error while (hopefully) avoiding the addition of any new requirements on date. Option 2 simplifies the description of date, but ends up adding an implication of mandatory '0' and '+' flags and minimum field width in date(1). I think this best belongs in TC1, by using option 1; whereas option 2 is better suited to Issue 8, perhaps by changing the resolution of 0000047. |
||||||
| Desired Action |
Option 1: At line 82887 [XCU date DESCRIPTION], under %C, replace: as a decimal number [00,99]. with as a decimal number, except that at least two digits are always printed. Option 2: Replace lines 82877-82957 [XCU date DESCRIPTION] with: +format When the format is specified, the output shall be formatted as if by strftime( ), with each conversion specifier being replaced with the appropriate contents based on the date selected, and all other characters output without change. The output shall always be terminated by a <newline>. [note that option 2 obsoletes the changes in 0000047 and has an impact on the wording of 0000169] |
||||||
| Tags | issue8 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
|
Notes |
|
|
(0000873) nick (manager) 2011-06-30 16:27 edited on: 2011-06-30 16:30 |
Option 2: Replace lines 82877-82957 [XCU date DESCRIPTION] with: +format When the format is specified, the output shall be formatted as if by strftime( ), with each conversion specifier being replaced with the appropriate contents based on the input time as the equivalent of localtime(time(0)) if -u is not specified or gmtime(time(0)) if -u is specified, and all other characters output without change. A <newline> shall always be appended to the output of strftime(). |
|
(0000966) geoffclare (manager) 2011-09-14 09:15 |
On the mailing list Don pointed out that localtime(time(0)) is incorrect code since localtime() takes a pointer to time_t, not a time_t. Replace lines 82877-82957 [XCU date DESCRIPTION] with: +format When the format is specified, the output shall be formatted as if by strftime() with the specified format string, and a timeptr argument that is the equivalent of localtime(&now) if -u is not specified or gmtime(&now) if -u is specified, where now is an object of type time_t containing the return value of time(0). A <newline> shall always be appended to the output of strftime(). |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2011-06-24 21:07 | eblake | New Issue | |
| 2011-06-24 21:07 | eblake | Status | New => Under Review |
| 2011-06-24 21:07 | eblake | Assigned To | => ajosey |
| 2011-06-24 21:07 | eblake | Name | => Eric Blake |
| 2011-06-24 21:07 | eblake | Organization | => Red Hat |
| 2011-06-24 21:07 | eblake | User Reference | => ebb.date |
| 2011-06-24 21:07 | eblake | Section | => date |
| 2011-06-24 21:07 | eblake | Page Number | => 2575 |
| 2011-06-24 21:07 | eblake | Line Number | => 82887 |
| 2011-06-24 21:07 | eblake | Interp Status | => --- |
| 2011-06-24 21:13 | eblake | Relationship added | related to 0000047 |
| 2011-06-24 21:13 | eblake | Relationship added | related to 0000169 |
| 2011-06-30 16:21 | msbrown | Tag Attached: issue8 | |
| 2011-06-30 16:27 | nick | Note Added: 0000873 | |
| 2011-06-30 16:27 | nick | Status | Under Review => Resolved |
| 2011-06-30 16:27 | nick | Resolution | Open => Future Enhancement |
| 2011-06-30 16:29 | nick | Note Edited: 0000873 | |
| 2011-06-30 16:29 | nick | Note Edited: 0000873 | |
| 2011-06-30 16:30 | nick | Final Accepted Text | => See Note: 0000873 |
| 2011-06-30 16:30 | nick | Note Edited: 0000873 | |
| 2011-06-30 17:37 | Don Cragun | Relationship replaced | has duplicate 0000047 |
| 2011-07-08 16:02 | Don Cragun | Resolution | Future Enhancement => Accepted As Marked |
| 2011-09-14 09:15 | geoffclare | Note Added: 0000966 | |
| 2011-09-14 09:15 | geoffclare | Status | Resolved => Under Review |
| 2011-09-14 09:15 | geoffclare | Resolution | Accepted As Marked => Reopened |
| 2011-09-22 16:03 | nick | Final Accepted Text | See Note: 0000873 => See Note: 0000966 |
| 2011-09-22 16:03 | nick | Status | Under Review => Resolved |
| 2011-09-22 16:03 | nick | Resolution | Reopened => Accepted As Marked |
| 2019-02-21 17:28 | eblake | Relationship added | related to 0001184 |
| 2020-01-30 16:58 | eblake | Relationship added | parent of 0001307 |
| 2020-03-05 15:04 | geoffclare | Status | Resolved => Applied |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
