illumos gate

The obvious fix for this would be:

diff -r 52f259cd114f usr/src/cmd/localedef/data/en_US.UTF-8.src
--- a/usr/src/cmd/localedef/data/en_US.UTF-8.src    Mon May 09 22:31:13 2011 -0400
+++ b/usr/src/cmd/localedef/data/en_US.UTF-8.src    Fri May 13 12:28:02 2011 -0400
@@ -7117,7 +7117,7 @@
         "<N><o><v><e><m><b><e><r>";/
         "<D><e><c><e><m><b><e><r>" 

-d_fmt    "%m<SOLIDUS>%e<SOLIDUS>%y" 
+d_fmt    "%m<SOLIDUS>%d<SOLIDUS>%y" 

 t_fmt    "%I:%M:%S %p" 

However, several localedef data files appear to use %e where %d
might have been expected. These all need further review.

I would argue that it is very very wrong for Evolution to be parsing this format, as it is highly locale sensitive.

However, I'm in agreement that %e is probably wrong here... we got this data from Unicode.org, and it seems many locales suffer a similar problem.

I'm not sure what the best resolution here is. We should check the Unicode 6.0 drop and see if it is any better.

It looks like in this case, the application is using the pair of functions:
strftime(3c), strptime(3c), to implement an editable "time" field, and
quite resonably expects strptime to be able to parse strftime results.
So maybe it's a strptime bug. Not sure which.

so the problem appears to be in strptime's implementation of %e. It does not handle a leading space.

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.

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.
[ Opened new issue for this cleanup: 1198
https://www.illumos.org/issues/1198 ]

(And yes, the parser for %e really should deal with the
leading space, but that does not make the above d_fmt
definitions any less ugly:)