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

        admin Paul Phillips created issue -
        admin Paul Phillips made changes -
        Field Original Value New Value
        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:

        {code:java}
          $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'));
          }
        {code}

        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)
        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:



        {code:java}
          $this->Date->setLocale(Configure::get('Blesta.language')); // NEW in 5.13.1
          $this->Date->setTimezone('UTC', Configure::get('Blesta.company_timezone'));

        {code}


        {code:java}
          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'));
          }
        {code}



        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)
        admin Paul Phillips made changes -
        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:



        {code:java}
          $this->Date->setLocale(Configure::get('Blesta.language')); // NEW in 5.13.1
          $this->Date->setTimezone('UTC', Configure::get('Blesta.company_timezone'));

        {code}


        {code:java}
          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'));
          }
        {code}



        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)
        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:

        {code:java}
          $this->Date->setLocale(Configure::get('Blesta.language')); // NEW in 5.13.1
          $this->Date->setTimezone('UTC', Configure::get('Blesta.company_timezone'));

        {code}

        And another new setLocale() call was added around line 947 in the setLanguageSettings() method:

        {code:java}
          // Set language to Date helper
          if (isset($this->Date)) {
              $this->Date->setLocale(Configure::get('Blesta.language'));
          }
        {code}



        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)
        admin Paul Phillips made changes -
        Summary Investigate potential month date name Investigate potential month date name display issues
        admin Paul Phillips made changes -
        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:

        {code:java}
          $this->Date->setLocale(Configure::get('Blesta.language')); // NEW in 5.13.1
          $this->Date->setTimezone('UTC', Configure::get('Blesta.company_timezone'));

        {code}

        And another new setLocale() call was added around line 947 in the setLanguageSettings() method:

        {code:java}
          // Set language to Date helper
          if (isset($this->Date)) {
              $this->Date->setLocale(Configure::get('Blesta.language'));
          }
        {code}



        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)
        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:

        {code:java}
          $this->Date->setLocale(Configure::get('Blesta.language')); // NEW in 5.13.1
          $this->Date->setTimezone('UTC', Configure::get('Blesta.company_timezone'));

        {code}

        And another new setLocale() call was added around line 947 in the setLanguageSettings() method:

        {code:java}
          // Set language to Date helper
          if (isset($this->Date)) {
              $this->Date->setLocale(Configure::get('Blesta.language'));
          }
        {code}



        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.

        jonathan Jonathan Reissmueller made changes -
        Sprint 5.14.0 Sprint 2 [ 224 ]
        jonathan Jonathan Reissmueller made changes -
        Rank Ranked higher
        jonathan Jonathan Reissmueller made changes -
        Assignee Jonathan Reissmueller [ jonathan ]
        admin Paul Phillips made changes -
        Security Private [ 10000 ]
        jonathan Jonathan Reissmueller made changes -
        Status Open [ 1 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        jonathan Jonathan Reissmueller made changes -
        Status In Review [ 5 ] Closed [ 6 ]

          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