Skip to main content

It appears that the Universal GUI uses the application language (as specified via user preferences) to determine the display of columns with the datetime2 datatype. However, this seems to be undesired behavior. I would expect the Universal GUI to rely on the settings configured for the IAM user instead.

In the Windows application, we use the WindowsCulture parameter in the .ini file.

As Niverplast is an international company, we use English as the default application language. However, since our headquarters are located in the Netherlands, my Dutch colleagues have been assigned the time zone ID Europe/Amsterdam in IAM.
 

 

I notice that when changing the application language via user preferences, this update is correctly reflected in IAM, which is good. However, the usr time_zone_id does not seem to have any functional value.
 

 

 

Does the lack of functional value for usr_time_zone_id indeed qualify as undesired behavior and thus a bug?

Hi Dennis,

The time zone configured for the user only has effect when the stored date-and-time fields are explicitly marked as being expressed in the UTC time zone.

Domains | Thinkwise Documentation

By default, they are configured to be shown as stored, without the user time zone offset being applied.

The language/culture should only affect the format of the date and time.

I have a question regarding how time zones are handled in our application and how this can be implemented consistently.
 

Anne Buit:

"The time zone configured for the user only has effect when the stored date-and-time fields are explicitly marked as being expressed in the UTC time zone."

 

Our configuration:

  1. Domains > Datetime > Time zone: set to "Local"
  2. IAM > Users > Time zone: set to "Europe/Amsterdam"

My expectation:
When a Dutch user creates a record on December 5, 2024, at 13:30, this timestamp would be stored as 13:30 in the SQL database and displayed in the user interface in the Europe/Amsterdam time zone. However, I am currently observing a different result.

Possible issue:
We populate our trace fields (such as insert_date and update_date) using the SQL function GETDATE(). This function uses the server's time zone, which leads to inconsistencies when users operate in different time zones. I believe it would be more logical and consistent to use SYSUTCDATETIME() instead, ensuring that all timestamps are stored in UTC.

Questions:

  1. Is it correct that using SYSUTCDATETIME() is preferred over GETDATE() to ensure consistency?
  2. Does the conversion from the database value to the local time zone (as configured in IAM) assume that the stored value is in UTC and then calculate the appropriate time zone offset based on this?
Insert date = "2024-12-05 13:29:52.8100000” based on GETDATE()

 

IAM - Time zone id "Europe/Amsterdam”
IAM - Time zone id "Etc/GMT”

I would appreciate any insights or best practices on this matter. 

When using the domain time zone setting “Local”, the value will be assumed to be an UTC date and time. You should indeed use the SYSUTCDATETIME() function to populate the trace fields.

The value will be transformed by the GUI from the UTC time to the time zone of the user. This also works vice-versa, when the value is manually entered by the user.

Does this answer your questions sufficiently?

Hi ​@Dennis van Leeuwen, did Anne his responses answer all the questions you have regarding this topic, or do you require further assistance?

Reply


Terms & ConditionsCookie settings