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
$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
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).
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 ...
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.
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
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 release.
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.
[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 en_US.UTF-8 [brad@fio ~]$ Note that this system isn't fully up2date. Perhaps it's been fixed in subsequent releases?
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.
(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.
The man page doesn't state anything that is untrue. Format YYYY-MM-DD is OK. The problem in comment #9 is year 2222.
see: http://pw1.netcom.com/~rogermw/Y2038.html