Bug 175327 - Documentation of usermod -e date format is wrong
Documentation of usermod -e date format is wrong
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: shadow-utils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
David Lawrence
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2005-12-08 17:18 EST by Brad Smith
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-13 07:47:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brad Smith 2005-12-08 17:18:23 EST
man usermod says:
  -e expire_date
      The date on which the user account  will  be
      disabled.  The date is specified in the for-
      mat YYYY-MM-DD.

but actually:
  [brad@fio ~]$ sudo usermod  -e 2222-01-31 foo
  usermod: invalid date `2222-01-01'
  [brad@fio ~]$ sudo usermod  -e 01-31-2222 foo
  [brad@fio ~]$

So the docs should like MM-DD-YYYY as the date format
Comment 1 Peter Vrabec 2005-12-15 11:07:10 EST
$sudo usermod  -e 2037-01-31 foo 
works for me.

I don't think 
$sudo usermod  -e 01-31-2222 foo 
is allright. 
Check with 
$chage -l foo
Comment 2 Brad Smith 2005-12-15 12:38:06 EST
Interesting. I experimented and found this:

[brad@fio ~]$ sudo usermod  -e 2056-01-31 foo
[brad@fio ~]$ sudo usermod  -e 2057-01-31 foo
[brad@fio ~]$ sudo usermod  -e 2058-01-31 foo
usermod: invalid date `2058-01-31'
[brad@fio ~]$ sudo usermod  -e 2059-01-31 foo
usermod: invalid date `2059-01-31'

Any date above 2057 seems to return an error. This will pose an annoyance at
best for people who use far-future dates to re-enable expried users (not that
that's a good practice, but I'm sure it's still done).
Comment 3 Peter Vrabec 2005-12-16 04:17:31 EST
I found out that u can specify maximal date 
$ sudo /usr/sbin/usermod  -e 2037-12-31 foo

because this doesn't seem to be allright:
$ sudo /usr/sbin/usermod  -e 2057-01-31 foo
$ sudo chage -l foo
Account expires                                         : never

Comment 4 Steve Grubb 2006-09-01 09:48:08 EDT
I'd be willing to bet that the date format is dependent on your locale. Maybe
the man page should say that and state what the example's locale was for reference.
Comment 5 Peter Vrabec 2006-09-11 09:00:23 EDT
According to libmisc/strtoday.c:44,
I would say that the day format might by one of:
 *      1970-09-17     # ISO 8601.
 *      70-9-17          # This century assumed by default.
 *      70-09-17        # Leading zeros are ignored.
 *      9/17/72          # Common U.S. writing.
 *      24 September 1972
 *      24 Sept 72      # September has a special abbreviation.
 *      24 Sep 72       # Three-letter abbreviations always allowed.
 *      Sep 24, 1972
 *      24-sep-72
 *      24sep72
Comment 6 RHEL Product and Program Management 2006-09-11 10:47:59 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 8 Peter Vrabec 2006-09-12 04:24:15 EDT
Even thou I have all three ACKs, I don't know what is the problem and how to fix it.

Brad, could u try another date formats(comment #5) and send your locale setting. Thnx.
Comment 9 Brad Smith 2006-09-12 09:08:52 EDT
[brad@fio ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
[brad@fio ~]$ sudo usermod  -e 2222-01-31 foo
usermod: invalid date `2222-01-31'
[brad@fio ~]$ echo $LANG
[brad@fio ~]$

Note that this system isn't fully up2date. Perhaps it's been fixed in subsequent
Comment 12 RHEL Product and Program Management 2006-10-12 17:15:14 EDT
Quality Engineering Management has reviewed and declined this request.  You may
appeal this decision by reopening this request. 
Comment 13 Brad Smith 2006-10-13 01:23:09 EDT
(In reply to comment #12)
> Quality Engineering Management has reviewed and declined this request.  You may
> appeal this decision by reopening this request. 

Given that comment #9 demonstrates that this problem is still relevant in
RHEL4u3, I would like to know why the request was declined. If it's been fixed
in a subsequent release, shouldn't it be FIXED instead of WONTFIX? If, on the
other hand, it hasn't been fixed, why ignore it? The man page still states
something that is untrue, at least using the default LANG setting. 
Comment 14 Peter Vrabec 2006-10-13 05:26:35 EDT
The man page doesn't state anything that is untrue. Format YYYY-MM-DD is OK. The problem 
in comment #9 is year 2222.
Comment 15 Peter Vrabec 2006-10-13 07:41:45 EDT

Note You need to log in before you can comment on or make changes to this bug.