08.05.2026
20:21
Hi everyone,
whenever you are working with times you are bound to run into issues. I think this has and will be a permanent truth when working with computers.
I currently "just" want to write a date time to an item list column and won't to return the same value. Seems simple, but time zones are proving to be a problem.
For the column "Enable time selection" and "Use time zone settings" has been enabled.
I'm updating the workflow instance with this value:
{
"guid": "0e8c5c68-7f88-43a2-b5ff-0d91e4eb051c",
"value": "2026-04-23T09:06:05Z"
},
This represents 9:06:05 UTC on my client this equals 11:06:05 local time (UTC+1:00 Amsterdam, Berlin...)
In the database it's saved with this time:
2026-04-23 09:06:05
When I'm fetching the element again via REST API i get this result:
{
"id": 331,
"guid": "0e8c5c68-7f88-43a2-b5ff-0d91e4eb051c",
"svalue": "2026-04-23T09:06:05.0000000+02:00",
"value": "2026-04-23T09:06:05+02:00"
},
This represents 7:06:05 UTC / 09:06:05 local time (UTC+1:00 Amsterdam, Berlin...)
The SQL server and WEBCON share the same machine and for whatever reason the time zone is also set to (UTC+1:00 Amsterdam, Berlin...).
The global parameter is also set to the equivalent time zone:
PRM_Name PRM_Value
DatabaseTimeZone W. Europe Standard Time
It sems, that the saved date time value is treated as local time of the server and the time zone offset is just added. While this makes sense to agree. It doesn't make sense when that the send UTC time is not converted to the local time.
Am I missing something or has someone a better idea on how I can utilize the public API and get the correct time?
It can't be, that the client has to send the times in the time zone the server is running. How should a consumer of the REST API know this?
Edit:
Current workaround, which I don't like at all:
# For some reason WEBCON does return the send UTC time with the time zone offset
$savedModifiedDate = [datetime]::Parse($modifiedDateCell.value.substring(0, 19) + 'Z')
Best regards,
Daniel
