|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76073 IntlCalendar seems to use LC_MESSAGES instead of LC_TIME (start of week)
Submitted: 2018-03-09 12:23 UTC Modified: 2021-11-11 11:18 UTC
From: mikko dot rantalainen at peda dot net Assigned:
Status: Open Package: I18N and L10N related
PHP Version: 7.0.28 OS: Ubuntu Linux 16.04 LTS 64 bit
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2018-03-09 12:23 UTC] mikko dot rantalainen at peda dot net
From manual page:

The manual does not define how default locale is defined. As a result, reader probably expects PHP to follow default locale system and honor LC_TIME (with LC_ALL override if set). However, in reality PHP honors LC_MESSAGES by default.

Test script:
$ LC_MESSAGES=en_GB.utf8 LC_TIME=en_GB.utf8 php -r 'var_dump(intlcal_get_first_day_of_week(intlcal_create_instance()));'
$ LC_MESSAGES=en_US.utf8 LC_TIME=en_GB.utf8 php -r 'var_dump(intlcal_get_first_day_of_week(intlcal_create_instance()));'

Expected result:
Command line code:1:
Command line code:1:

Actual result:
Command line code:1:
Command line code:1:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-03-09 13:47 UTC]
-Package: Date/time related +Package: intl
 [2018-03-09 15:43 UTC]
There's two parts to this:

1. PHP is requesting the default locale from your installed libicu and they are the ones using LC_ALL or LC_MESSAGES. So that part is not a bug.

2. PHP does have to choose a locale for IntlCalendar operations. Same for a few other intl methods. So PHP could prefer using LC_whichever when available.
 [2018-03-12 07:28 UTC] mikko dot rantalainen at peda dot net
I agree that libicu should use default PHP locale. However, when PHP initializes time or date related features, it should definitely use LC_TIME instead of LC_MESSAGES. LC_MESSAGES is about localization of end user visible message strings and LC_TIME is about localization of end user visible time and date content.

I think this bug is about the fact that intl_locale_get_default() is used in various places in the PHP code where the code should make difference between collations (LC_COLLATE, in practice character order), language of displayed messages (LC_MESSAGES) and time/date display (LC_TIME).

As listed by the code always uses intl_locale_get_default() for all these cases which is definitely incorrect.

PHP really needs at least three locale specific default values or (preferably, IMO) it should just trust the system wide LC_COLLATE, LC_MESSAGES and LC_TIME environment variables. And display a warning message if any of those settings are missing.

Any modern correctly configured OS will populate LC_* variables system wide.
 [2021-06-30 09:46 UTC]
I don't think it would be a good idea to use standard locale info
for ICU, since this works per process, and causes massive issues
with multi-threaded PHP builds.
 [2021-11-11 11:18 UTC]
-Package: intl +Package: I18N and L10N related
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 14:01:31 2024 UTC