Incorrect date, time and number formatting in the Backend API and shop integrations

Summary

During a planned migration of our application servers on 24 August 2026 (04:00–08:00 CEST), dates, times and numbers returned by our Backend API and shop integrations started using a different regional format than before. Times were returned with a period instead of a colon (12.30 instead of 12:30), and decimal numbers with a comma instead of a period (1,50 instead of 1.50). We became aware of the issue the same morning and it was resolved on 25 August at 02:18 PM CEST. All formatting is now back to how it was before the migration.

Impact

The Backend API and our shop integrations were affected. Anyone with a custom implementation that depended on the exact previous formatting of dates, times or numbers could see errors or read values incorrectly, since the payloads we sent contained a different separator than expected. Because the two new servers were configured differently from each other, the same request could return either format depending on which server handled it, making the behaviour appear intermittent.

One customer reported the issue, but it could have affected any integration relying on exact formatting during the affected period. Payloads delivered during the window cannot be corrected after the fact, so if you stored or processed values from the Backend API or a shop integration between 24 and 25 August, we recommend verifying them and re-fetching if needed.

Cause

The new application servers were provisioned with different regional settings. One used a Danish locale (comma as decimal separator and period as time separator) and the other a US English locale (period as decimal separator and colon as time separator). Values formatted according to the server's regional setting therefore changed compared to the previous setup, and were inconsistent between the two servers.

Resolution

We identified the difference in regional settings as the cause and deployed a code change that explicitly locks the formatting used by all affected applications to the same format as before the migration, independent of how the underlying server is configured. Formatting is now consistent across all servers and matches pre-migration behaviour. No action is required from customers, and integrations that were failing are working again.