Hi,
I am working with OutSystems (ODC) and receiving a date-time value from an external API written in .NET.
The API returns the value in the following format:
"2026-02-01T13:13:13.797"
This value represents local time in Israel.
In OutSystems, I store this value in a Structure with a DateTime type. When I display it on the screen using:
FormatDateTime( TextToDateTime(DocumentDate), "dd/MM/yyyy HH:mm:ss")
the displayed time is two hours ahead (15:13 instead of 13:13).
I understand that ODC treats all DateTime values as UTC and automatically converts them to the browser’s local timezone.
My question is: What is the correct way to send and store a DateTime from a .NET API to OutSystems ODC so that a local Israel time is displayed as-is (13:13), without performing manual hour calculations and without losing timezone information?
I think u should use UTC for the external API written in .Net. Because we make sure the time server is UTC and don't care OS auto convert time in UI.
Have 2 way:
1. U can edit time in .NET.
2. U get time from external API and convert it LocalTimeToUTC before u save into DB.
Hope this helps!
If the .NET Api team is not on your side, to edit is impossible.
If you know the exact time zone of the Api server, I recommend to manually convert it to UTC whenever received from Api. Then you can store it / use it directly.
Actually, you can seek for help from the Api team to return the time zone gap, too. So that you know how many hours gap to convert to UTC in ODC.
Hello
Since time is coming through external API, better way to get it fixed from API itself. Any manipulation on front end side is not a best practice and could lead to some other issue.
Thanks
Gaurav
The easiest way is to pass it as text so it isn't interpreted as a datetime.
Then on screen you just convert to datetime and display it, no timezone changes.
If possible, could you change the API to include the timezone offset in the datetime as well? For example: 2026-02-06T14:30:00+01:00.
With this, ODC should serialize it correctly to UTC. Based on my past experience with .NET and datetime handling, this usually works as expected. However, I can’t guarantee it for ODC since I’m not familiar with the exact generated .NET code behind it.
thank you for the response.
From my understanding, there is no option in OutSystems to disable or prevent the timezone adjustment applied to DateTime values received from an API. This means the solution is to return UTC time or a DateTimeOffset (with an offset) from the API, and there is no solution on the OutSystems side itself.
Is my understanding correct?
Your understanding is correct @hava sh .In ODC Reactive, the DateTime type is localized by the browser by design. There's no "disable" toggle. The platform assumes you want to present time in the user’s local context.
I tested this on an ODC External Logic (.NET 8) environment to dig into the mechanics. It isn’t an OutSystems bug but a serialization Contract mismatch.
When a .NET API returns a DateTime where the Kind property is Unspecified, the JSON serializer produces a string without the "Z" suffix (e.g., "2026-05-20T10:00:00"). Without that "Z", the browser assumes the time is "floating" and applies your local timezone offset. I believe that’s exactly where your +2 hours are coming from.
Test and check your Network Tab:Open Chrome DevTools (F12) and look at the raw JSON response from your API. You'll likely see the issue:
Bugged response: "2026-05-20T10:00:00" (No 'Z' -> Browser adds offset).
Fixed response: "2026-05-20T10:00:00Z" (Has 'Z' -> Browser respects it as UTC).
If you have access to the API code, fix the contract at the source. Ensure the DateTimeKind is set to Utc before returning the object so the "Z" is generated:return DateTime.SpecifyKind(yourApiDate, DateTimeKind.Utc);
Even better, use DateTimeOffset. It’s never ambiguous because it explicitly includes the offset (example +00:00), forcing the platform to handle the time correctly every time.
I've attached the .NET source code I used to verify this behavior. In addition to the advice already given, fixing the source is the clean, architectural way to solve this without resorting to "Text" hacks or manual AddHours logic.