7

Right now API/service-to-service calls use the global ServicesDefaultTimeZone, while normal web users use their own timezone settings. This can cause weird differences where CurrentDateTime, Today, etc. behave differently in API sessions vs UI sessions.


We recently hit this with an external weighing integration. The API payload itself contained the correct local weighing time, but later BC business logic calculated a Time field using CurrentDateTime inside the Entra integration REST session. Since that session was running in UTC, the final shipment time ended up a few hours wrong even though the original API data was correct.

The tricky part was that this calculated field was then used as input for another government integration where, by law, the allowed time difference is only 20 minutes. So a timezone mismatch inside the API session can actually break legally required integrations.

We solved it for now by changing the server-level ServicesDefaultTimeZone, but that only really works on-prem. Older BC automations running under real BC users never had this issue because those users could log in normally and have their own timezone settings. REST/Entra integrations don't really have an equivalent mechanism today.

Feels like the Entra app setup page would be the perfect place for this, since we already manage Client IDs and permissions there anyway. Would also avoid changing server-wide config and would work nicely for both SaaS and on-prem.

Category: Development
STATUS DETAILS
New

Comments

I

While this approach has merit, it may not work well for countries or deployments spanning multiple timezones. A more robust solution could be to leverage an OData timezone property to pass a timezone context with each API request, applying it for the entire session. This would allow external systems to manage timezone handling independently, while ensuring that datetime functions in Business Central — such as Today() or Time() — operate correctly throughout the session. Indirectly triggered objects like the Service Document Log would also benefit from the correct timezone context without requiring any additional adjustments.

Category: Development