Project

General

Profile

Bug #1198

date formats contain spaces where not expected

Added by Gordon Ross about 9 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Yuri Pankov
Category:
locale - data and messages
Start date:
2011-05-13
Due date:
% Done:

100%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

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)

History

#1

Updated by Gordon Ross about 9 years ago

Here are some more observations from
Gary Mills (sent to )

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

#2

Updated by Gordon Ross about 9 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.

#3

Updated by Gordon Ross about 9 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.

#5

Updated by Yuri Pankov about 3 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.

#6

Updated by Electric Monk about 3 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>

#7

Updated by Yuri Pankov almost 3 years ago

Just for the record, this didn't make it into CLDR v32.

Also available in: Atom PDF