Your application works perfectly in Bangladesh.
Then a user in the United States reports that an appointment appears on the wrong day.
Nothing looks wrong in the database.
Welcome to time zones.
Time-related bugs are surprisingly common because developers often mix local time, UTC, and browser time without realizing it.
Store Time Consistently
A common approach is to store timestamps in UTC.
Then convert them to the user's local time when displaying them.
For example:
Database: 2026-09-10 06:00 UTC
Bangladesh: 12:00 PM
New York: 02:00 AM
The same moment can look completely different depending on the user's location.
Don't Guess the User's Time Zone
Your server's time zone isn't necessarily the user's time zone.
A server can be located in one country while users are distributed around the world.
For user-facing applications, the browser or account settings can provide the appropriate time zone.
Dates Are Even Trickier
“September 10” sounds simple.
But if your application stores an exact timestamp and converts it between time zones, the displayed calendar date can change.
That's why booking systems, calendars, reminders, and scheduled tasks need special attention.
Test With Multiple Time Zones
Don't test only with your own computer.
Try:
Bangladesh US Europe Australia
You don't need a complicated test suite to discover every issue.
Even a few different time zones can reveal assumptions hidden in your code.
The Rule Worth Remembering
Store consistently. Convert at the edges.
Time zones are not just a frontend problem.
They affect databases, APIs, scheduled jobs, notifications, and business logic.
Handle them intentionally before users discover the bugs for you.