Hi Team,
I just wanted to share an issue I encountered in my current project related to time handling and storage.
We are using an external database, and users select a specific time (e.g., 9:00 AM). However, when the data is stored in the database, the time is saved as 11:30 AM — showing a 2.5-hour difference. In some cases, the time difference is 2 hours and 34 minutes.
Interestingly, when we fetch and display the time on the client side, it appears correctly as 9:00 AM. But when exporting the data to Excel, the exported time shows as 11:30 AM, which is not what the user expects.
After some R&D, I found that OutSystems automatically converts time values between client and server based on the respective time zones. This automatic conversion is likely causing the discrepancy.
To resolve this, I changed the way we send time values from the client to the server. Instead of sending a full DateTime, I now split the time into hours and minutes on the client side. On the server side, I reconstruct the time using the NewDateTime() function in OutSystems.
With this approach, the user-selected time, the value stored in the database, and the time shown in exports (Excel, PDF, etc.) are now consistent — exactly as expected by the users.
Hope this helps others facing similar issues.
Thanks!
@Rameshkannan V : What you are observing is actually the correct behavior. OutSystems stores DateTime values in UTC (or in the timezone configured for the database). When rendering in the browser, the value is automatically converted to the user’s local timezone.
However, there is a flaw in your implementation. If I understood correctly, you are sending only the hour and minute to the server instead of a full DateTime value, and then recreating the DateTime on the server using those values.
Consider this example: if the user selects 28-Jul-2025 10:30 PM, you send 22 (hour) and 30 (minutes) to the server. Since your server is ahead by 2.5 hours (as you mentioned earlier), the reconstructed time becomes 29-Jul-2025 10:30 PM, which is incorrect.
This approach will also fail if users access the system from different time zones, as the reconstructed DateTime will not correctly reflect the user’s intended selection.
For exporting data on the server side, a better approach is to store DateTime values as UTC (default behaviour) and, when generating reports, adjust the time to the user’s timezone before exporting.