What defines a day - When technical implementation affects business behaviour

Bartosz Osiński — Fri, 03 Jul 2026 15:17:04 +0000

As a programmer, what is the first thing you think about when you start working on a new feature?

Probably you try to plan all the changes in code. You ask yourself:

Does my backend provide this data?
How will it affect existing code? How should I implement this feature to avoid code duplication?
What about performance? Maybe I need to do some debouncing or throttling?

These are all valid, important questions. But at what point do you really start thinking about the feature you’re about to implement?

I’ll be honest with you, sometimes I start thinking about how the feature is supposed to work much too late. I get excited about all the cool stuff I can do, all the smart patterns I can use, and I run straight to the implementation. Then, after it’s finally time to connect all these small lego bricks I just implemented to build it into a fully functioning feature I notice that something is wrong. Half of the code should have been written differently, and the other half I don’t need at all.

All because I approached the task as a programmer, while this feature is designed for application users.

Let’s think about it in practice.

An example

Here is a simple, hypothetical web application. On the calendar you can mark any cell as holiday by clicking on it, and then the whole cell becomes red.

Have you noticed a bug? When you click on some date, the day before gets actually marked as holiday.

If you’re one of the few (un-)lucky ones who reside in a location where this bug is not reproducible, try spoofing your location for chrome:

Open Developer tools
Click on “⋮” button and select “More tools” > “Sensors”.
In the location fields try, for example, “Tokyo”.

let’s now imagine for a moment that this example above is a part of big, commercial product.

A new version gets released and creators of this app are immediately flooded by clients’ angry support tickets and bug reports.

And at the same time, but on the opposite part of the globe there is some equally frustrated developer who got assigned to fix this bug, but he can’t reproduce it for the life of him.

So what is the cause of this problem?

Each calendar cell is represented here by a single Date object, created like this:

new Date(2026, 2, 1)

Of course, passing three arguments there doesn’t mean that this object points at whole day. There is still information about time of day, it just defaults to midnight at the location that the user is in.

March 1st 2026 00:00 in Tokyo is February 28th 15:00 in London. It’s the same point in time, globally, but represented by different numbers in different parts of the globe.

So what happens when user clicks on a cell? The date representing this cell gets added to the array of holidays, and then this array gets passed to saveHolidays function, which stores it in local storage. Here’s how this function looks like:

const holidaysLocalStorageKey = 'holidays';

export function saveHolidays(holidays: Date[]): void {
  const data = holidays
    .map(date => `${date.getUTCFullYear()}-${date.getUTCMonth() + 1}-${date.getUTCDate()}`).join(',');

    localStorage.setItem(holidaysLocalStorageKey, data);
}

Before saving the date it gets transformed into a string looking like this: 2026-3-1 . But we use UTC methods, and they won’t return the date in Tokyo in this specific point in time, they will return the UTC date, which is shifted 9 hours earlier relative to Tokyo’s time.

We can guess that the UI part of the code and the persistence part were probably written by two different developers. One of them assumed that Date object should always be treated as local date, including timezone information, while the other decided to treat this date as universal.

The fix is fairly simple, really. Either:

Always treat the date as local.

So, in our saveHolidays function we could serialize the date this way instead:

`${date.getFullYear()}-${date.getMonth() + 1}-${date.getDate()}`

Always treat the date as universal.

So, instead of creating it using new Date(2026, 2, 1) we can do: new Date(Date.UTC(2026, 2, 1)) .

Whichever way we choose, we need to be consistent.

So, now we have our fix, and a fairly simple one, but the problem still exists - it is code that is easy to misuse and introduce bugs.

The fact that this bug got introduced is a clear sign of poorly designed code.

Back to the real world

Let’s imagine a simple scenario:

I have a regular, paper calendar. I want to call my friend, and ask him to point his finger at exactly the same cell in this calendar as I’m pointing at. My friend could be my next door neighbour or he could live in a different country. That doesn’t matter. I’d call him and say:

“Hey, do you have a 2026 calendar? Please open it on a page with April and point your finger to cell with number 14, okay?”

Ignoring the fact that it is a weird thing to ask your friend for, he would point into exactly the same cell as I’m pointing at. I didn’t need to tell him any information about time and timezones. It was a simple message, but it didn’t need to be any more complicated.

When an application is designed, it’s supposed to be intuitive for its users. One solution for that is to mimic the real world, something that the user is familiar with.

I’m sure that when product manager was designing this feature they took that into account and expected this calendar in an app to work the same way as my real-life example above.

And it’s for the best when our code reflects that, from the deepest level.

“To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.”

― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

By handling our data in a way that reflects app’s intended behaviour we not only ensure that the app will work as intended at the current stage - we also make sure that it will stay this way, as doing something against business rules will require a refactor, which in turn will ignite an idea in a developer’s head: “Maybe I’m doing something wrong”.

So what data should represent our cell? Maybe something like this:

enum Month {
    JANUARY,
    FEBRUARY,
    // ...
}

interface CalendarDate {
    year: number;
    month: Month;
    day: number;
}

That would prevent our bug from ever existing. There’s no time information here, nor any timezone shifts. There is simply no space for this bug to happen.

On the downside, this requires much more work. We need to write a lot of utilities for this object: Comparing them, serializing and deserializing, retrieving all days present in a month might still require usage of Date at some point, as we can’t really naively calculate how many days there are in a specific month at a specific year.

In a perfect world, we would get as much time as we need to create perfect code. Unfortunately…

…we’re not living in a perfect world.

There are deadlines, sprints and growing backlog. It’s impossible to polish every single bit of code that we conceived.

I definitely don’t want to say that whoever chose to represent a calendar cell as a Date object is a bad developer. He had to find the best ratio of quality and efficiency, and for the most part where this ratio lies on a scale is a matter of opinion, not a hard fact.

What I’m trying to say in this (maybe slightly too philosophical :P) article is this:

First of all, model the domain correctly.

Maybe you’ll write a perfect code this way, or maybe just something barely acceptable, but either way, I believe that we’re all going to benefit from this approach in the long run.

Now, going back to our calendar. There is an ECMAscript proposal that probably a lot of you have already heard (It’s even implemented in some javascript runtimes already) called Temporal.

It’s a new way of handling dates and time, and it gives us exactly what we need in our case: Specialized objects for storing only dates, datetimes, or durations between two datetimes.

I believe that thanks to that we’re going to see much less time-related bugs in the future.

DEV Community: Bartosz Osiński

What defines a day - When technical implementation affects business behaviour

An example

So what is the cause of this problem?

Back to the real world

…we’re not living in a perfect world.