Today I’m coining the term “the calendar problem” to describe any system that has irregular rules,(1) which require complex logic to implement or check. My goal when creating any system is to bound any calendar problem logic to make validation as simple as possible.
Can’t be avoided; can be minimized
In systems, calendar problems will exist but they can be minimized through a 4 step process.
- Determine the core “default” rules: this is the behavior of the system unless an exception occurs.
- Determine the exceptions: what is the logic for when the core rules do not hold.
- Determine the exceptions to the exceptions: this is both when the exceptions do not hold and when there is a different result for the exception
- Look for back propagation: do the exceptions change any of the earlier results?
Calendar example
We will walk through the calendar to show how this can be applied
- Core / Default
- 365 days in a year
- Jan, March, May, July, Aug, Oct, Dec : 31 days
- Sept, April, June, Nov : 30 days
- Feb 28 days
- Modifications:
- Every 4th year Feb has 29 days
- The year has 366 days.
- Modifications to modifications
- If the year is divisible by 100 it is not a leap year
- If the year is divisible by 400 it is a leap year
- Back propagation
- None
Humans and irregularities….
Irregularities come in when you have human interactions with your system; physics is always regular. The key is to look for situations where the person in the loop has conflicting needs or may not know there is an issue (so they act in ways that are not in alignment with what they want).
Footnote
- The “knuckles / spaces” method for knowing which months have 28 / 29 / 30 or 31 days was something I just found today. What is interesting is that it shows the problem even as it offers help; the darn 28 / 29 February (not even getting into the 4, 100, 400 year issues here).