Where is the session time offset stored?

4
I am working on a project that is used in different timezones. I need to do some calculations on a localized DateTime attribute and store the result into a non localized one. When I am doing my calculations, I can see (in the debugger) that the session time offset of every object is different. My question is now: Is the session time stored at the object? Or is it stored at the attribute? Does it represent the timezone of the user who created this object (attribute)? Is it his timezone based on his timezone settings, or based on his local system settings? Will it change when another user commits this object? Thanks for your help. [Edit 1] It seems like this behavior is based on some sort of a setting. One of our test systems shows that behavior, the other one does not. We are still investigating.
asked
2 answers
1

Hi Andreas,

To corroborate what Ronald already stated, a dateTime in Mendix is always stored without timezone information regardless of the localize checkbox. You can confirm this for yourself by inspecting the db in pgAdmin (for PostgreSQL).

That said, the differences in session time offset is probably due to Daylight savings time. So dates that are in winter time will have different UTC offset as compared to dates in summer time. To check this I logged the offset for a localized DateTime attribute for a user with Timezone set to UTC-8 during summer time. Here are two representative dates:

UTC time: 2012-07-23 22:00:00.000
Session time: 2012-07-23 15:00:00.000 -0700

 

UTC time: 2012-02-10 23:00:00.000
Session time: 2012-02-10 15:00:00.000 -0800

Hope this helps,

Andrej

answered
2

When working with multiple timezones this is a must read: https://docs.mendix.com/refguide/datetime-handling-faq

Note that a date time is always committed to the database in UTC.

Regards,

Ronald

[EDIT]

I think this part is the most important one for you:

The time zone setting for a user defines under what time zone operations are performed for this user on the server, for example when a Microflow formats a DateTime value as a String to get the current hour of the day. Note that this is different from operations in the users browser. Unfortunately it is not possible for browsers to operate under a different time zone than either the one of the browsers computer or the UTC time zone. This means that users should set their time zone to the one their browser runs on, or they might notice discrepancies in what is displayed in their browser and (for example) generated documents or formatted strings. Note that if you do not set a timezone to a user, the server only knows the offset from UTC that the browser reports of the current moment, which can lead to unexpected results when dealing with dates in a different period of the year after a Daylight Savings Time adjustment.

[EDIT2]

I think you still miss the point here. All DateTime fields are stored in the database in UTC. The localize boolean influances only how this UTC time is shown to the user. Example Wed Sep 06 06:31:28 2017 UTC in the database will be shown as Wed Sep 06 08:31:28 2017 CEST in my timezone if localize was set to true. But on false it would just show the UTC time. But the value in the database would not change. So if another user opens this entity and saves it again the attribute would stay the same unless the user changed the value.

answered