I have a datetime field for an entity in a simple form called "Observation Date". I have a date picker displaying with just "Date" (no time) as the date format and the following validation to make sure the field is required AND also NOT in the future: $value != empty and $value <= [%CurrentDateTime%] The current server local time is set to GMT-500 (EST) Yesterday Oct 25th around 2pm (14:00), the user entered "10/25/2022" (Oct 25th). It triggered the validation, telling them the date was in the future. Clearly it was not. Does the "CurrentDateTime" variable make any call to the server to see what the current time is, or does it rely on the client computer's clock? If so, then my guess is the only thing that triggered this is if the user's clock was incorrectly set to a time zone to the west (before the international date line). For example, if it was Oct 25th, but their clock accidentally said Oct 24th, would this have possibly caused the violation.. or if they were on in EST but their computer's clock was Pacific time (3 hours behing), could possibly have triggered this. If the latter is the case then that would mean that even though only the date was showing in the field, there's something behind the scenes that's keeping track of the exact minute they selected the date.
asked
Brian Lorraine
2 answers
2
Hi Brian,
The Mendix Server operations use the time zone of the user instead of the server time zone. Previously operations like generating documents, exporting to Excel/CSV and date computations in microflows/OQL all used the server time zone. This is fine if the server and all users of your application are in the same time zone. If they are not, however, generated output can contain unexpected results
Sure enough, the user's local clock was set to an incorrect dateSure enough, the user's local clock was set to an incorrect date… It makes me think if server side validation on the date is better since that will always be constant.