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

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?
1 answers

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.