On 2016-08-06 21:08, Julian Elischer wrote:
On 6/08/2016 11:09 PM, Benjamin Kaduk wrote:
On Sat, 6 Aug 2016, Baptiste Daroussin wrote:
On Sat, Aug 06, 2016 at 02:15:36PM +1000, Greg 'groggy' Lehey wrote:
On Friday, 5 August 2016 at 18:56:33 +0300, Andrey A. Chernov
wrote:
On 05.08.2016 18:44, Mark Martinec wrote:
On 2016-08-05 17:23, Andrey Chernov wrote:
POSIX does say that the default format should be the same
as with "+%a %b %e %H:%M:%S %Z %Y".
It also says that %a and %b are locale's abbreviated names.
It is true for _POSIX_ locale only, as I already say. en_US.* is
not
POSIX or C locale.
It still violates POLA.
I really do not think that it violates POLA fiven that the behaviour
you are
expecting is still available in the default configurtion that is
still POSIX.
Regardless, at a new major release is precisely when it is permissible
to
break POLA.
switching from short form to long form is more than a POLA.. short
form has a specific fixed layout
and feeding a long form string into it will break things.
Set LC_TIME to C and then you are back on your behaviour (and this is
the
default when you install FreeBSD).
locales should be seen as tzdata for exemple, they are a moving
target
complicated to handle for every locale we do support: 78 for
11.0-RELEASE and
193 if we do count the encoding variants. locales are updated very
often (for
exemple cldr unicode make a new release of the data every 8 month or
so)
As I understand it, your change will improve the maintainability of
locales in FreeBSD in the future, which justifies a POLA break at the
release boundary.
-Ben
$ LC_ALL=en_US.UTF-8 date
FreeBSD 11.0-BETA3 :
Friday, August 5, 2016 at 03:20:25 PM CEST
FreeBSD 10.3-RELEASE-p6 :
Fri Aug 5 15:15:11 CEST 2016
OSX version 10.9.5 :
Fri Aug 5 14:57:14 CEST 2016
Fedora Linux 4.6.4-301.fc24.x86_64 :
Fri Aug 5 15:10:40 CEST 2016
Debian 8.0 / Linux 4.4.16-v7+ :
Fri Aug 5 15:25:49 CEST 2016
It's not just long vs. short forms of a name, it is also the order of
fields,
their separators, and a 12/24h time form that is different from everyone
else
and from what we used to have in 10.3. Is it really worth being
different?
I wonder how many ad-hoc scripts will break.
Although as Andrey Chernov correctly noted that the date(1) specs in
The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition
( http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html )
says that the default format applies to POSIX locale only:
STDOUT
When no formatting operand is specified, the output in the
POSIX locale shall be equivalent to specifying:
date "+%a %b %e %H:%M:%S %Z %Y"
imo, unless there is a very good reason not to, the above default format
should be applicable to most locales, but at least to English spoken
locales. The explicit locale-dependency of %a, %b, and %Z conversion
specifications already takes care of most locale-specific
idiosyncrasies.
Mark
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
