Austin Group Defect Tracker

Aardvark Mark IV


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 2024-06-11 08:53
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
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
related to 0000169Closedajosey 1003.1(2008)/Issue 7 date utility needs ``%s'' 
parent of 0001307Closed 1003.1(2016/18)/Issue7+TC2 am_pm value in locales that do not distinguish between am and pm (again) 
has duplicate 0000047Closedajosey 1003.1(2008)/Issue 7 Missing specifiers for date utility 
related to 0001184Closed 1003.1(2016/18)/Issue7+TC2 strftime %C padding character unspecified 

-  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
2024-06-11 08:53 agadmin Status Applied => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker