formatDateTime() with unlocalized datetime attribute

7
I came across unexpected behaviour when working with unlocalized dateTime attributes in Mendix. I would like to ask you if this is desired behaviour. When you choose not to localize a dateTime attribute the exact dateTime that is entered in the attribute will be saved in the database, the debugger shows this as UTC time (This is strange because it has nothing to do with UTC right?). The source of the dateTime can be a datepicker on a form or a web service, XML import or Microflow change action. This does not affect the way the dateTime is saved. When you use a formatDateTime() formula to convert the unlocalized dateTime to a string the localized time is suddenly used while I would expect that it would use the exact dateTime value I entered in the attribute. Example: I have a dateTime attribute BirthDate. The option localize is false in the domain model. I enter 01-01-2015 with a datepicker. When I save the object and debug I see UTC time: 01-01-2015 00:00:000 Session time: 01-01-2015 01:00:000 +0100. Why do you see a session time then localize is turned off? Now I parse the BirthDate attribute with this formula parseDateTime($Person/BirthDate,'dd-MM-yyyy HH:mm') I would expect to get the exact date I filled in, 01-01-2015 00:00 but I get 01-01-2015 01:00. Is this correct? When I use parseDateTimeUTC() I get the correct time but in my opinion there should be no difference between parseDateTime() and parseDateTimeUTC() when parsing unlocalized dateTimes.
asked
1 answers
5

This is by design, though I also find it confusing. It has been the root of a number of bugs I've seen in Mendix applications.

You can actually accomplish a lot of date conversion functionality using the UTC and non-UTC functions, but I too wish there were a function that respected the data model localization setting.

As a general rule, make sure to always use the UTC functions for non-localized datetimes and the regular function for localized datetimes.

answered