Unexpected 1‑hour date shift when using parseDateTimeUTC() on non‑localized Date attribute after March 2026

0
Hi all,DateTime is always a bit confusing and I’m running into a strange and inconsistent issue involving date parsing in a server‑side microflow that is triggered by an API POST.We have an entity TheoreticalExamResult with an attribute ExamDate:Type: Date and TimeLocalize = falseAssigned via microflow using: parseDateTimeUTC($StringValue, 'dd/MM/yyyy')The input string is a pure date, e.g.: "10/03/2026" What happens locallyWhen I test everything in my local runtime, the parsed date looks correct: UTC time: 2026‑03‑10 00:00:00.000 Session time: 2026‑03‑10 01:00:00.000 (+0100)What happens in the test environmentIn the cloud test environment, the exact same input produces: UTC time: 2026‑03‑09 23:00:00.000 Session time: 2026‑03‑10 00:00:00.000 (+0100)So the UTC value is shifted by −1 hour.This issue only appeared somewhere around the 8th–10th of March 2026.What is the issue here and how can I fix it?
asked
1 answers
2

Hi Mona,


I think the most likely cause is a difference in explicit time zone configuration between the environments. Mendix applies DST correctly when a proper time zone identifier is available (for example, Europe/Amsterdam). However, if no identifier is available, it falls back to the current UTC offset, and in that case DST may not be applied correctly for past or future dates, which can result in a 1-hour shift. This matches the behavior you are seeing. Date and Time Handling | Mendix Documentation





The timing is also quite telling: DST in the United States started on March 8, 2026, while DST in Europe does not start until March 29, 2026. Since the issue appeared around March 8–10, it suggests that the test environment may be resolving the session/user time zone based on a US time zone, an offset fallback, or another setup that is not fully DST-aware.


Could you please check:

- in which region/location the test environment is running/hosted,

- which time zone is configured for the runtime/user context in that environment,

- which time zone value is assigned to the account that is making this API call? In particular, it would be useful to verify the time zone of the integration user, service account, or anonymous user context used for the request.


Strictly speaking, Mendix documentation states that the server time zone is generally only relevant for scheduled events, while most other date/time operations use the end-user or session time zone. Still, knowing the hosting region/location can help determine whether an unexpected offset fallback or environment-specific configuration may be influencing the behavior.


Hope this helps



answered