What Defines a Day?
Programmers often focus on the wrong things when building new features.
You might think about backend data, code duplication, or performance. These questions matter. But they are not the most important questions.
I often make this mistake. I get excited about smart patterns and clean code. I start coding before I fully understand how the user uses the feature. Then I realize my code does not match the business goal.
Take a calendar app as an example.
A user clicks on March 1st to mark a holiday. But the app marks February 28th instead. This happens because of timezones.
The developer used a Date object. A Date object represents a specific moment in time.
In Tokyo, March 1st at midnight is still February 28th in London. If your code uses UTC methods to save the date, the day shifts.
The bug exists because the technical implementation contradicts the business logic.
A user thinks in days. A user does not think in UTC offsets or millisecond timestamps. They think: "I want March 14th."
If you want your code to be reliable, you must model the domain correctly.
In a paper calendar, a date is just a year, a month, and a day. It has no timezone.
You can fix the bug by being consistent with UTC or local time. But that is a band-aid. A better way is to use data structures that cannot fail.
Instead of a Date object, use a custom object:
• Year: 2026 • Month: March • Day: 1
This removes time and timezones from the equation. It makes the bug impossible.
Yes, this takes more work. You have to write utilities to compare dates or find the end of a month. You have deadlines and sprints to worry about.
But modeling the domain correctly saves you from angry support tickets and hours of debugging later.
As Eric Evans says in Domain-Driven Design:
"To communicate effectively, the code must be based on the same language used to write the requirements."
Stop thinking only as a programmer. Start thinking about the business rules.