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.