Assigning to maintainer.

Assignee: bugsquad => mageia

did you try without ".utf8"?
setlocale(LC_TIME, "fr_FR");

Is this locale installed on your machine? Tested your code with en_US, de_DE which are my locales, runs without issues and correct results.

Without utf8, same effect.
Know that my system is migrated from Mageia 6. These instructions were used in my application and was working in PHP7.2 before the migration.
My system is localized in French, of course.
locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

And with fr_FR.UTF-8, same effect too.
Possible related problem: 
https://www.mageialinux-online.org/forum/topic-26353-1+nextcloud-vs-locales.php

can you check the output of
setlocale() - it will return the locale that is in effect:
<?php
$date = "2019-01-31";
echo $date."\n";
echo setlocale(LC_TIME, "de_DE")."\n";
echo 'date:'.date(' F d.m.Y',strtotime($date))."\n";
echo '1:'.strftime("%e %B %Y",strtotime($date)) . "\n";
setlocale(LC_TIME, "en_GB");
echo '2:'.strftime("%e %B %Y",strtotime($date));
?>
$ php -v
PHP 7.3.8 (cli) (built: Aug  1 2019 09:43:08) ( NTS )
$ php test.php
2019-01-31
de_DE
date: January 31.01.2019
1:31 Januar 2019
2:31 January 2019

did you check /etc/php.ini.rpmnew and /etc/php.d/*.rpmnew
05_date.ini
may be relevant.

I assume this will give you your package?
$ rpm -qa locales-fr

I've installed that package myself, switched "de_DE" to "fr_FR" and get:
2019-01-31
fr_FR
date: January 31.01.2019
1:31 janvier 2019
2:31 January 2019

With your code, from the console:
php test_locale.php 
2019-01-31
fr_FR
date: January 31.01.2019
1:31 janvier 2019
2:31 January 2019

But, from the browser:
2019-01-31 fr_FR date: January 31.01.2019 1:31 January 2019 2:31 January 2019

In this case, output 1 is not localized, although it is from the command line.
Is the php command line using the apache server?

rpm -qa locales-fr
locales-fr-2.29-3.mga7

strange, currently I've no server running apache-mod-php anymore, all servers using php-fpm. On php-fpm, everything is ok.

Can php-fpm be substituted to apache-mod-php ?

at least for security, memory and maintenace I suggest using php-fpm. By using php-fpm you do not depend on apache, but you can still use it, if you need or like it :)

Switching from mod-apache to php-fpm, you can use sockets or network to connect the php-fpm deamon. Each php-fpm process can run with a different user.
In apache you have to pass the file to the php-fpm process e.g. like this:

ProxyPassMatch ^/(.*\.php)$ unix:///var/run/php-fpm/www.sock|fcgi://127.0.0.1:9000/home/demo/www/ flushpackets=auto timeout=1800


You'll have to read some manual, php-fpm and proxying from apache is sometimes a bit complicated, but it is worth the work :)

Hi,

First, sorry for have not jumped into this thread earlier, as papoteur advised me, especially because he found this because of me (trying to figure out why my nextcloud was displaying some strange missing locales error).

I have made some more tests based on papoteur's ones:
- my production installation is also a migration from 6 to 7
- I have installed a VM, checking the setlocale working, then applied an upgrade to 7: the setlocale is still working
- I have tried your php-fpm but I might be missing something (according to your post, there is some customization to do), I have a 403 Forbidden: execute access forbidden (service is started)
- $locale_result=setlocale(LC_TIME, "fr_FR.utf8");
result is fr_FR.utf8
$locale_result=setlocale(LC_TIME, "fr_FR");
result is fr_FR
$locale_result=setlocale(LC_TIME, "fr_FR.UTF-8");
result is fr_FR.UTF-8
$locale_result=setlocale(LC_TIME, "fr_FR.utfZ8");
empty result (excepted behavior I assume with unknown locale)
- locale -a returns a long list of them, including the requested ones, the IS-88591 ones, @euro, ... I reinstalled the files without success
- locales-fr-2.29-3.mga7 ; apache-mod_php-7.3.9-1.mga7 ; lib64php_common7-7.3.9-1.mga7
- 05_date.ini: md5 on good&bad environments are equal

Let me know if I may try some other things
Thanks.

CC: (none) => nicolas.bachelet1

(In reply to Marc Krämer from comment #5)
> can you check the output of
> setlocale() - it will return the locale that is in effect:

I missed this question.
It returns nothing in the browser.
In command line, I get 
PHP Warning:  setlocale() expects at least 2 parameters, 0 given

Hi Marc,
I'm trying to set php-fpm, but fail.
I have installed 
php-fpm
apache-mod_proxy
apache-mod_proxy_html

I have a local application installed in /var/www/html/dolibarr which an index.php in directory htdocs
Usually I have access to it without virtualhost at localhost/dolibarr/htdocs.

I have launched php-fpm and restarted apache with default configuration. But I never got the socket at /var/lib/php-fpm/php-fpm.sock although this is set in /etc/php-fpm.d/www.conf
I have more success by setting access through net.
I built a virtualhost file setting the server at http://dolibarr which get the main page only, but not the other php files to laod are not found (error 404). I have in my virtualhost file:
<VirtualHost *:80>
ServerName dolibarr
ServerAlias dolibarr
UseCanonicalName On
AddDefaultCharset UTF-8
DocumentRoot "/var/www/html"
ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9000/var/www/html/dolibarr/htdocs/$1 flushpackets=auto timeout=1800
...

Have you some ideas?

Still no clue regarding what is broken in our environments or how/what to do to find the root cause?

I did not tried again php-fpm as we might still have our issue...

Hello,
I finally obtained that php-fpm works, using some mod_rewrite.
Thus, no explanation of the root cause.
Papoteur

sorry for the delay, I was on vaccation.

Btw. you told it was working in mga6 using the apache module. Did it work with the backported php 7.2 or did you use php 5.6?

sorry for the delay, I was on vaccation.

Btw. you told it was working in mga6 using the apache module. Did it work with the backported php 7.2 or did you use php 5.6?

sorry for the delay, I was on vaccation.

Btw. you told it was working in mga6 using the apache module. Did it work with the backported php 7.2 or did you use php 5.6?

(In reply to Marc Krämer from comment #19)
> Btw. you told it was working in mga6 using the apache module. Did it work
> with the backported php 7.2 or did you use php 5.6?
For my side, I was using the backported php7.2

ok, since there are no changes from php 7.2 to 7.3 on setlocale and the build process for php 7.2 and 7.3 are similar, it may be an general mga7 issue or some change in apache.
The documentation says "The return value of setlocale() depends on the system that PHP is running. It returns exactly what the system setlocale function returns."
So maybe apache prevents/blocks setting the locale. At least setlocale works on the process, not the thread so you can always encounter racing conditions using setlocale.

[root@machine ~]# urpme apache-mod_perl
To satisfy dependencies, the following 4 packages will be removed (3.6MB):
  apache-mod_perl-2.0.10-6.mga7.x86_64
  perl-SOAP-WSDL-3.3.0-4.mga7.noarch
   (due to missing perl(APR::Table),
    due to missing perl(Apache2::Const),
    due to missing perl(Apache2::Log),
    due to missing perl(Apache2::RequestIO),
    due to missing perl(Apache2::RequestRec))
  task-lamp-3-7.mga7.noarch
   (due to missing task-lamp-perl)
  task-lamp-perl-3-7.mga7.noarch
   (due to missing apache-mod_perl)
Remove 4 packages? (y/N) y
removing apache-mod_perl-2.0.10-6.mga7.x86_64 perl-SOAP-WSDL-3.3.0-4.mga7.noarch task-lamp-3-7.mga7.noarch task-lamp-perl-3-7.mga7.noarch
removing package perl-SOAP-WSDL-3.3.0-4.mga7.noarch
      1/4: removing perl-SOAP-WSDL-3.3.0-4.mga7.noarch
                                 #############################################
removing package task-lamp-1:3-7.mga7.noarch
      2/4: removing task-lamp-1:3-7.mga7.noarch
                                 #############################################
removing package task-lamp-perl-1:3-7.mga7.noarch
      3/4: removing task-lamp-perl-1:3-7.mga7.noarch
                                 #############################################
removing package apache-mod_perl-1:2.0.10-6.mga7.x86_64
      4/4: removing apache-mod_perl-1:2.0.10-6.mga7.x86_64
                                 #############################################
[root@machine ~]# service httpd restart
Redirecting to /bin/systemctl restart httpd.service

=> locales are working again in PHP
=> papoteur: do you confirm it solves your issue too?
=> do not know what/why...

strange, so mod_perl has influence on mod_php...

Hello,
 urpme apache-mod_perl

This has no effect by me.
perl-SOAP-WSDL wasn't installed.

(In reply to papoteur from comment #24)
> Hello,
>  urpme apache-mod_perl
> 
> This has no effect by me.
> perl-SOAP-WSDL wasn't installed.

Sorry, I didn't restarted apache.
Now, after restarting, this is OK!
Should we consider apache-mod_perl as the culprit?

How to solve that?

Ever confirmed: 0 => 1
Status: UNCONFIRMED => NEW

not sure what we should do in future. I think most built in cgi-modules will be dropped sooner or later.
It is not a good idea to use them in combination, but it is way easier to setup...
Using cgi makes more trouble until the setup works as expected.

php should be used with php-fpm - if not, things like this can happen in a shared environment like apache.

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED