Unexpected behaviour when setting a non-localized DateTime attribute in a custom widget

1
I'm working on a custom widget and I see strange behaviour when setting a non-localized datetime attribute on a object from within my widget: This is my code in the widget: if (obj.isLocalizedDate("myDateTimeAttribute")) {     console.warn('attribute is a LOCALIZED date'); } else {     console.warn('attribute is NOT a LOCALIZED date'); } obj.set("myDateTimeAttribute", 0) Timestamp 0 is UTC time 1970-01-01 00:00:00 and timestamps are independent of timezones, since it is an offset from UTC. I have configured my "myDateTimeAttribute" in the domain model as not-localized. The above code confirms that by showing "attribute is NOT a LOCALIZED date" in the console. What I expected in this case that if I pass timestamp 0 to a not-localized datetime attribute that it will be set as "1970-01-01 00:00:00 UTC", but instead I'm getting “1970-01-01 01:00:00 UTC” back in my microflow. If I change the timezone in my OS (i'm in CEST) than the value changes too, so it seems that timestamps are being treated as localized on client side. That confuses me since timestamps are on offset from UTC, so should be indepent from a users timezine. I can offcourse do a correction based on the browser’s timezone in my widget, but it doesn't feel right to do timezone correction on timestamps... Am I missing something?
asked
2 answers
1

First check if, when you switch ‘myDateTimeAttribute’ to localized in Mendix, that your tests shows

'attribute is a LOCALIZED date'

But if that proves to be correct, I expect this to show a bug in Mendix in the passing of any date-attribute to widgets. Might want to open a ticket to Mendix for it, if this is reproducable.

answered
0

This is the answer I got from Mendix Support about this behaviour:

 

Hopefully, you had a nice weekend. I've discussed your query with our internal team and found the following:

 

  • Plain JavaScript does not deal with timezones or database storage, so that causes that MxObject.set("MyAttribute", 0) to work differently for a non-localized datetime attribute (which is a Mendix-specific concept) than a simple new Date(0)​.
  • Non-localized DateTime attributes are meant to represent the same day in the client as what is stored in the database, regardless of which timezone you're in. That makes them more complicated to work with when dealing directly with MxObject (the new pluggable widget APIs deal with this transparently). The non-localized datetime attributes should be used where only the date part is relevant and the time part can be ignored. 
  • if you want to store exactly 1970-01-01 0:00 in the database (UTC), you need to call MxObject.set() with a timestamp that corresponds with 1970-01-01 0:00 CET (in other words, new Date("1970-01-01 0:00").getTime(), which is -3600000 if you're in the Europe/Amsterdam timezone).

While I understand that may not be what you expected, hopefully, this sheds some light on the situation.

answered