Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.13.1
-
Fix Version/s: 5.13.2
-
Component/s: Staff Interface
-
Labels:None
Description
Some users are reporting the wrong month name appearing (December in January). Here's a summary of recent changes that might be worth investigating. Attached is a diagnostic test that may or may not be helpful, it checks whether dates match, upload to Blesta docroot and access in browser.
New line added at line 307:
$this->Date->setLocale(Configure::get('Blesta.language')); // NEW in 5.13.1 $this->Date->setTimezone('UTC', Configure::get('Blesta.company_timezone'));
And another new setLocale() call was added around line 947 in the setLanguageSettings() method:
// Set language to Date helper if (isset($this->Date)) { $this->Date->setLocale(Configure::get('Blesta.language')); }
This is the change introduced in 5.13.1 - the setLocale() call was added to enable internationalized month names via IntlDateFormatter.
While setLocale() shouldn't directly affect timezone conversion, it does affect how the IntlDateFormatter renders month names. If there's an incompatibility between the locale setting and the IntlDateFormatter behavior (or if Configure::get('Blesta.language') returns an unexpected value), it could cause formatting issues.
The user should:
1. Check what value Configure::get('Blesta.language') returns
2. Verify their PHP intl extension is properly configured
3. Try temporarily removing or commenting out the setLocale() calls to see if that fixes the display issue (this would confirm it's locale-related)
Customer Report in Discord
Same issue... dates were correct, updated to 5.13.1 just now, and now dates for Jan show Dec instead, on Transactions list.
If I change the date format to "m d, Y" it displays 01 15, 2026... but M and F are wrong.
If I add my timezone before the cast in admin_company_general_localization.pdt:
$this->Date->setTimezone('America/Los_Angeles'); // PST
Then it displays ok... and if I add that in admin_billing_transactions.pdt then that displays ok as well.
So somewhere it lost the timezone?
It's client-facing as well... so a global issue.
I'm able to get it to pass or fail based on the timezone I set in Localization, that should help us to reproduce.