Today I was debugging a question of a client of ours and came a across a weird thing in Mx 4.8.8. When I have a date attribute in my model where localize is set to off and use the calendar to fill a date I get this result for today the 2nd december of 2014: 2014-12-02 23:59:59.999 (see screenshot of postgres). Now take this microflow: Just to debug I created the DayBegin and DayEnd because the retrieve xpath should return objects but did not. Now the result of the breakpoint (look at the DayEnd): Notice the difference between 2014-12-02 23:59:59.999 vs 2014-12-02 23:59:59.998? Why does Mendix use 998 instead of 999? Regards, Ronald [EDIT] I have got a response from Mendix. This is at least the reason why of this behaviour: We have found the cause of this. We build this code in 2008 because sqlserver 2005 has limited precision when storing datetimes. It has a accuracy of 0.003 seconds. When we stored 23:59:59:999 in sqlserver, it was automatically rounded to the next day by sqlserver. So we set end of day to 998 to workaround this limitation of sqlserver. Solution is not yet clear: if we change it to 999 we will break it on sqlserver. Also, in the future we might want to support nano-seconds, so just relying on 999 might not be the right approach for application build on Mendix. Sollution is still another matter, that needs some further thought. But this is really something you need to be aware off . In microflows you can circumvent it with something like trimToSeconds(addMilliseconds([%EndOfCurrentWeekUTC%], 5)) But this does not work with xpaths in grids that use any of these tokens. And note that this behaviour is accross all Mendix versions (Mx3,4 and 5).