Bug #1198
closed
date formats contain spaces where not expected
100%
Description
LANG=en_US.UTF-8 date '+%x'
has unexpected form in the first 9 days of the month:
$ date '+%x' 05/ 6/11
(Note the space before the numeral six)
The older 8859 locales did not do that.
This also used to break strptime, but that's fixed.
(https://www.illumos.org/issues/1030)
Updated by Gordon Ross over 11 years ago
Here are some more observations from
Gary Mills (sent to developers@illumos.org)
I kept wondering why I've never seen this problem.
This is Solaris 10, where we're still using 8859 locales:
$ env LC_TIME=en_CA.ISO8859-1 date +%x 02/07/11 $ env LC_TIME=en_US.ISO8859-1 date +%x 07/02/11
This is Solaris 11 Express:
$ env LC_TIME="en_CA.UTF-8" date +%x 07/02/11 $ env LC_TIME="en_US.UTF-8" date +%x 07/ 2/11
This is OI 148:
$ env LC_TIME="en_CA.UTF-8" date +%x 11-07-02 $ env LC_TIME="en_US.UTF-8" date +%x 07/ 2/11
Updated by Gordon Ross over 11 years ago
[Copied Note 7 by Gary Mills from 1030]
I would say that the bug is in strftime. It should never
produce a condensed date string that contains an internal
space. Here's what I get now:
$ env LC_TIME=en_CA.ISO8859-1 date +%x 21/05/11 $ env LC_TIME=en_US.ISO8859-1 date +%x 05/21/11
If the day of the month in the second example has a
leading space, we have a problem. Now, strftime() has
no option letter to print single-digit day numbers. The only
choices are with a leading zero or leading space. Unless
strftime() can be modified to compress out spaces after
formatting, the only reasonable choice is the leading zero.
Updated by Gordon Ross over 11 years ago
[Copied my note 8 from 1030]
It does seem that the "%x" format is more commonly defined as
some permutation of "%Y", "%m", "%d" (and not "%e"), so
the result of %x will usually not contain spaces.
I did a "grep d_fmt" in $SRC/cmd/localedef/data
and the result is an interesting hodge-podge.
In general, the locale-specific aspects of d_fmt
are (1) the order, and (2) the separators.
Beyond that, most (all?) should use %Y rather than %y,
and where the day of the month is somewhere other than
the start of the d_fmt string, probably should be %d so
there will not be spaces within the result. (A space
at the front is probably harmless, so locales that use
d_fmt=%e/%m/%Y (for example) are probably fine.)
I suggest we cleanup the d_fmt definitions per above.
Updated by Toomas Soome over 5 years ago
Updated by Yuri Pankov over 5 years ago
- Status changed from New to In Progress
- Assignee changed from Gordon Ross to Yuri Pankov
- Priority changed from Low to Normal
- % Done changed from 0 to 50
- Difficulty changed from Medium to Bite-size
- Tags deleted (
needs-triage)
proposing the temporary fix until upstream data is updated.
Updated by Electric Monk over 5 years ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
git commit 5206305f06cf80338a34e00287f3336069e1198b
commit 5206305f06cf80338a34e00287f3336069e1198b
Author: Yuri Pankov <yuri.pankov@nexenta.com>
Date: 2017-06-28T15:21:15.000Z
1198 date formats contain spaces where not expected
Reviewed by: Toomas Soome <tsoome@me.com>
Reviewed by: Igor Kozhukhov <igor@dilos.org>
Reviewed by: Garrett D'Amore <garrett@damore.org>
Approved by: Dan McDonald <danmcd@joyent.com>
Updated by Yuri Pankov over 5 years ago
Just for the record, this didn't make it into CLDR v32.