Mendix supports localized time Date & Time Handling - Studio Pro 8 Guide | Mendix Documentation.
From the link:
Per attribute of type Date and time you can specify whether you want the date and time to be localized. This is not a new feature but worth mentioning on this page. Both localized and non-localized attributes are stored in UTC but only localized attributes are converted to the time zone of the user when displaying their value. Use non-localized attributes if you are not interested in the time component (e.g. birthdays) or if you want a date to look exactly the same all over the world.
This is good if it is important for users to know when something happened or will occur in their timezone.
In our use case we have scenarios that are tied to a location and an event, i.e something happened at 15:23 in New York. There is no value in showing what the users local time was when it happened.
It can be managed by using, as an example parseDateTimeUTC in microflows and parseDateTime in nanoflows.
This works most of the time except during DST (daylight saving time) changes. I am not sure if it is because I operate in/from Europe but the date 2020-10-25 and 2020-03-29 are special. At least that are the only places where I found problems.
Enter 2020-10-25 01:25 in any date picker with an attribute set to Localize = no and it changes immediately to 2020-10-25 02:25 but it will be saved as 2020-10-25 01:25 in the database.
Similarly 2020-03-29 01:25 becomes 2020-03-29 00:25 and 2020-03-29 02:25 becomes 2020-03-29 04:25
My hope and suggestion is that Mendix adds support for non-localized time as well.
you can use non-localized times without problems (normally – that bug is… well a bug).
Working across timezones is always a pain – not because of technology, but because of misconceptions of the meaning of time and timestamps (this faq is quite good: https://docs.mendix.com/refguide/datetime-handling-faq#1-introduction)
I did file a ticket and support acknowledged that something is weird. The thing is that time is only guaranteed when localized and therefore only supposed to be used if localized. That is why I suggest that Mendix also should support non-localized time.
In my use case I have users geographically spread around the world and they talk to each other about events happened in the past. The standard is that they always talk about the time as it where locally where it happened.
A Belgian user talks to an Indian user about what happened in New York 3 weeks ago. They need to look at when some events occured and how much time something took. Neither is interested in what time it was in Belgium or India during the event and going back and forth in time zones is guaranteed to create problems.
My thought is that this use case would be easily solved by having non-localized time. They enter and discuss the time element as if they where all in New York . If someone else have a good idéa I would like to hear it.
That ‘2020-10-25 01:25’ thing looks like a bug to me and you should file a support ticket for that. Apart from that I don’t really get your use case.