Datatype DateTime: suggestion to implement datatype Date

For an project that has to deal with multiple time zones I'm running into multiple issues because of Mendix only has the datatype DateTime and lacks the datatype Date. I guess the answer will be that Mx supports date because that's a DateTime with localize to false. But that isn't completely true. DateTime without localizing still stores a time that can cause trouble. When you are using UTCs in microflows you will notice a session time in the debugger. When not using the UTC carefully (addDaysUTC, formatDateTimeUTC, ...) you will definitely run into issues. An other example of a problem that occurred many times is that a Date (like invoice date) initially is configured with localize to true (because that's Mendix default). Someone in GMT+1 enters an invoice with date 05-12-2013 and it will be stored as 04-12-2013 23:00:00. After I while the users will start noticing issues because an invoice date can differ per timezone. Someone in a GMT timezone will see a date of 04-12-2013. Now you have a big problem because data is stored with a time that is depending on the user that entered the date. Setting localize to false for InvoiceDate will NOT do the trick anymore because now every user will see 04-12-2013 (because 04-12-2013 23:00 is now interpreted as an UTC). You have to create a database correction that adds one or more hours to the InvoiceDate to correct it to 05-12-2013 00:00. So to prevent (even experienced) business engineers from mistakes I strongly suggest a Date datetype for the Mendix framework. DateTime should only be used when, exactly, you are interested in a Date AND a Time. Some lessons learned when working with datetime (given the current platform limitations) that I'm happy to share: If you are only interested in a date (like invoice date, data of birth) be sure to set localize to false If you are also interested in a local(!) time (like planning an international meeting in local times) you use localize Changing localize property when already data is entered will give issues, you have to correct the data When working with UTC's in microflows be sure to use the ..UTC functions otherwise session time will be used I'll file a ticket for this but I'm also curious to other expeciences. And: the more upvotes the more back up for a feature request ;).
1 answers

Let me just play the role of the devil's advocate here for a bit.

Date, time, timezones, etc. and their implementations have what we call Essential Complexity. It's important to understand the complexity involved in any case and we can't make it much easier.

That said, of course it's possible to introduce a data type that only stores a date, but the next feature request will be to do calculations between regular datetime objects and these dates, or to convert between them, etc. Then you're back to square one, except it's now a more complex model.

Another argument is that there are of course cases where you don't need the time component, but you'll still have to understand localization, when to use it and how to convert it for all the other datetime attributes in your system.

These are just a few of the reasons why we've chosen not to do this yet, and of course it would take a lot of time (no pun intended)