A lot has been written about date and time handling in Mendix. There is no separate date or time type. All our storage involving dates and/or time data is done via a Timestamp, aka Date and Time type. This also brings some challenges, as even though you might just want to store one of them, you always have to deal with both. This could be a struggle when you do this during any ordinary year, month or day. February 29th, however, is a whole different beast. Computers calculate precisely as we instruct them, and a leap year is already a difficult concept for humans. You have a recipe for disaster when you add Mendix’s abstraction to the already challenged Java layer. In this edition of Mendix Ignite, I will explain the do’s and don’ts that have helped me prevent significant disasters during the last 3 leap years.

Don’ts

Let us dive into what you want to avoid first. 

‍

Directly calculating with leap day when you pass into the next year could have unforeseen consequences. As long as you are okay with that, nothing is wrong, but it is wise to avoid calculating with February 29th.

• For example, when you use the subtractYears[UTC] function to subtract 1 year from March 1st, 2025, you will get two different results when using the UTC version vs the “regular” version. The UTC version will give you February 28th, 2024, while the “regular” version gives you March 1st, 2024. (this is with the time set to 00:00:00.000), if set to a time later in the day, you will always get March 1st, 2024.
  
  This, however, does not apply when not passing leap day. In that case, it will return the expected same day from last year just fine.
• Subtracting 52 weeks (a common full-year number) also has some weird results, but that applies to both leap year-influenced and none-leap year-influenced calculations. Both end up on March 2nd, the year before. Even though one starts on February 29th, 2024 and the other on March 1st, 2025.
• If you expect to always end up on the same day of the year while adding 12 months or 1+ years, you should know that starting on February 29th will end on March 1st in the next year unless you add 4 or multiple of 4. In that case, you may safely land back on February 29th.

Using custom Java date calculations.

• There are several implementations of date handling in the Java arsenal. Unfortunately, not all of them are working as expected. Even Mendix has refined the inner workings of its interface with Java over the years. Try to leverage that and avoid calculating directly via Java if you find a blog like this to avoid any known issues.

‍

Do’s

And now some best practices you do want to apply.

Validate if you are in a leap year by using the following code snippet:

By doing so, you will avoid running into potential issues, or you can trigger some nice defensive code dealing with the issues.

‍

Validate if you are dealing with February 29th with the next code snippet:

This will allow you again to avoid potential issues for the leap day itself. Especially those scenarios described earlier.

‍

To try out some of this for yourself and get you started on leap year/day calculations, I have created a demo project, which you may download by going to the GitHub project page.
‍

Feel free to add your pull requests for additional scenarios and some of your leap-year issues + solutions in the comments.

‍

‍