Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-5669

Investigate potential month date name display issues

    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.

        Activity

        Hide
        admin Paul Phillips added a comment -

        I'm able to get it to pass or fail based on the timezone I set in Localization, that should help us to reproduce.

        Show
        admin Paul Phillips added a comment - I'm able to get it to pass or fail based on the timezone I set in Localization, that should help us to reproduce.
        Hide
        admin Paul Phillips added a comment -

        This resolves the issue in my testing and from what I understand is happening:
        https://github.com/phillipsdata/minphp-date/pull/21/commits/ad003c62d8fa67124ebeba579e0ab019068f18dd

        getMonth() doesn't care about what day it is, so it's treated essentially as January 1 (even though today is January 21), and hours earlier it would have been December. On January 21st at 7pm pacific time, the code creates "January 1st ~03:00 UTC", converts it to Pacific, gets "December 31st ~19:00 pacific", and IntlDateFormatter returns "December". That is the core issue. and the bottom line is that the method had no business doing timezone conversion at all because it just converts a month number to a localized name.

        Show
        admin Paul Phillips added a comment - This resolves the issue in my testing and from what I understand is happening: https://github.com/phillipsdata/minphp-date/pull/21/commits/ad003c62d8fa67124ebeba579e0ab019068f18dd getMonth() doesn't care about what day it is, so it's treated essentially as January 1 (even though today is January 21), and hours earlier it would have been December. On January 21st at 7pm pacific time, the code creates "January 1st ~03:00 UTC", converts it to Pacific, gets "December 31st ~19:00 pacific", and IntlDateFormatter returns "December". That is the core issue. and the bottom line is that the method had no business doing timezone conversion at all because it just converts a month number to a localized name.

          People

          • Assignee:
            jonathan Jonathan Reissmueller
            Reporter:
            admin Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              28/Jan/26

              Agile