Re: date(1) default format changed between 10.3 and 11.0-BETA3

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