Re: datestr failures

[Rik]

On 11/04/2013 02:40 AM, address@hidden wrote:
> Message: 3
> Date: Mon, 04 Nov 2013 10:52:32 +0100
> From: Julien Bect <address@hidden>
> To: Octave Maintainers <address@hidden>
> Subject: New failing tests for datestr (locale problem)
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Dear maintainers,
>
> Since recently, I see lots of failing tests (15 I think) related to datestr.
>
> Here are two of them :
>
>
> !!!!! test failed
> ASSERT errors for:  assert (datestr (testtime, 28),"Dec2005")
>
>    Location  |  Observed  |  Expected  |  Reason
>       []       d?c.2005     Dec2005      Strings don't match
> shared variables   scalar structure containing the fields:
>      testtime =
>         2.0050e+03   1.2000e+01   1.8000e+01   2.0000e+00 3.3000e+01  
> 1.7382e+01
>    ***** assert (datestr (testtime+[0 0 3 0 0 0], "dddd"), "Wednesday")
>
>
> !!!!! test failed
> ASSERT errors for:  assert (datestr (testtime + [0, 0, 3, 0, 0, 0],
> "dddd"),"Wednesday")
>
>    Location  |  Observed  |  Expected  |  Reason
>       []        mercredi    Wednesday     Strings don't match
> shared variables   scalar structure containing the fields:
>      testtime =
>         2.0050e+03   1.2000e+01   1.8000e+01   2.0000e+00 3.3000e+01  
> 1.7382e+01
>    ***** assert (datestr ([1944, 6, 6, 6, 30, 0], 0), "06-Jun-1944
> 06:30:00")
>
>
> I can make them disappear by changing LC_ALL before running Octave, but
> is this really what I'm expected to do ?
>
> This behaviour is new on my computer, and I don't think I saw any
> discussion on this list of this being an intentional change, but perhaps
> I missed something.
>
> @++
> Julien
11/4/13

Julien,

I can confirm this.  Could you file a bug report about it so it doesn't get lost?  The issue is that the old 'make check' used to call the CLI version of Octave which was not linked against the <locale> libraries.  The new way of starting octave invokes octave-gui even for the CLI.  octave-gui *is* linked against the GUI libraries and <locale> libraries so it interprets the fr_FR locale you have set.

We have previously verified that Matlab sets the LC_NUMERIC locale variable to 'C' regardless of the current locale setting.  This ensures that 1,3 is not interpreted as 1.3 in locales where the radix is ','.  I kind of doubt it, but Matlab might override LC_TIME as well.  Could somebody run Matlab under a fr_FR.utf-8 locale and report whether

--- Code ---
datestr ([1944, 6, 6, 6, 30, 0], 0)
--- End Code ---

reports 'Jun' or 'juin'?

For the time being you can work around this by setting the environment variable LC_TIME to 'C'.

--Rik