Bug 59444
Summary: | date --date assumes US-style format regardless of locale setting | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | jwitford |
Component: | sh-utils | Assignee: | Bernhard Rosenkraenzer <bero> |
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-02-15 21:56:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jwitford
2002-02-08 00:32:15 UTC
This is true; however, people (and their scripts) have come to expect this behavior because it has been that way forever. I'm not sure this should be fixed. It should be fixed. The longer it is left then the more people might make more erroneous assumptions in their scripts. And since the --date option accepts fairly free-form input (eg 2002/02/01, or 02/01/2002) it should conform with user's locale. Usually the date will derive from other data in locale's format. A fix will not affect any US script and us foreigners would really appreciate a fix because all our dates appear as 01/02/2002 and it is just plain silly if we have to mangle the date just to satisfy the --date option. Surely that is what locale's are all about - fixing this sort of problem! Unfortunately, in this case, "fixing" the problem could cause more harm than it is worth. I think that the only real solution would be to extend the date command with a --localedate command, so as not to break existing usage, as Bero mentions. But "... could cause more harm than it is worth ..." never stopped someone from changing "ls" collation order! A correction would not affact ANY user in the USA. It is a bug because it doesn't behave as expected. Moreover any workaround will usually involve the transformation of dd/mm/yyyy to yyyy/mm/dd because the latter form is unambiguous and always works. I couldn't imagine anybody doing a transformation of dd/mm/yyyy to mm/dd/yyyy as a workaround. POSIX (which demanded the collation order change) mandates the current date behavior. |