Imagine a spare parts wholesaler in Istanbul that has started selling to customers in Germany and the Gulf through an online portal. A customer in Berlin places an order at 23:30 on the last day of the month. In Istanbul it is already 01:30 the next day. The month-end sales report counts the order in the new month. The customer's invoice shows one date, the warehouse screen another, and the sales manager wonders why the rep's monthly target was missed by one order.
Nothing crashed. No error appeared in any log. The system did exactly what it was told; nobody had told it which day it was.
Time zone problems behave like this. They rarely stop the software, so they are rarely caught in testing. They show up as small disagreements between screens, reports and people, and they become expensive once the business crosses a border or a team starts working from more than one city. The rules below are cheap to settle at the start of a project and painful to retrofit later.
1. Store moments in UTC, and say so
When something happens at a specific instant, such as an order being placed, a payment going through or a user signing in, store that instant in UTC (Coordinated Universal Time) in the database. Convert it to a local time only when showing it to someone.
The reason is simple: UTC never shifts for daylight saving time, and it means the same thing on every server. If one part of the system writes Istanbul time and another writes server time, which might be in a data center in another country, there is no way to compare the two later.
Write this rule in the project documents. A new developer joining in a year should not have to guess what a timestamp column holds.
2. Not every date is a moment
Some dates are not instants and should never be converted. A birthday, a contract end date, a public holiday or the date printed on an invoice are calendar dates. A birthday on 14 March is 14 March in every country.
If these are stored as timestamps and converted for display, a customer in New York can see their birthday as 13 March. Keep calendar dates as plain dates, without a time and without a time zone. Before building a screen, ask of each date field: is this a moment, or a day on the calendar?
3. Decide whose day it is
A "day" in a report needs an owner. Is the sales day the day in Istanbul, where the company is based, or the day where the customer is? Both answers are reasonable; having no answer is not.
For most companies the answer is the head office's time zone for internal reports, and the customer's own time zone for anything the customer sees, such as an order confirmation. Write the choice down for each report. In the wholesaler's example, deciding that monthly reports follow Istanbul time is fine, as long as the sales team knows it and the targets are set the same way.
4. Cut-off times belong to a place
"Orders placed before 14:00 ship today" is a promise made in a specific city. The warehouse is in one place, and the cut-off belongs to that place, not to the customer and not to the server.
Store such rules together with their time zone, and show the customer the cut-off in their own time where it matters: "Order within the next 2 hours 10 minutes for same-day dispatch" is clearer than "before 14:00" to someone two hours away.
The same applies to support hours, delivery slots and appointment times. An appointment at a clinic happens in the clinic's time zone, whatever time zone the patient booked it from.
5. Check when your nightly jobs actually run
Many systems run scheduled jobs "at midnight": closing the day, sending a summary email, syncing stock with another system. Servers often run in UTC, so a job set for midnight on a server in UTC runs at 03:00 in Istanbul, or at 01:00 in Berlin in winter and 02:00 in summer.
Sometimes that is harmless. Sometimes the day-end job closes the day before a late order has arrived, or a stock sync runs in the middle of a busy evening for customers in another region. List your scheduled jobs, write next to each one the local time it is meant to run, and check that the server settings match.
6. Daylight saving time still exists elsewhere
Turkey has stayed on a fixed offset since 2016, which makes it easy for a team in Istanbul to forget that most of Europe and North America change their clocks twice a year. A customer in London is three hours behind Istanbul in winter and two hours behind in summer, and the change happens on different dates in Europe and the United States.
This is why fixed offsets, such as "Germany is UTC+1", should never be written into code. Store time zones by name, for example "Europe/Berlin", and let a maintained time zone library work out the offset for each date. On the two change days each year, run a quick check of anything time-sensitive: scheduled jobs, reminders and appointment slots.
7. Show the time zone when it is not obvious
When a screen shows a time and the reader could reasonably be in another city, show the zone next to it: "Delivery slot 10:00 to 12:00 (Istanbul time)". It takes a few characters and prevents a misunderstanding that would otherwise turn into a phone call.
For internal users, let each person set their own time zone in their profile instead of guessing from the browser. A manager travelling for a week should not see all the reports shift by two hours.
A quick test
Change your computer's time zone to somewhere far away, such as Los Angeles, and go through the main flows of your system: place an order late in the evening, open today's report, book an appointment, check an invoice date. Every date that changes where it should not, and every one that stays the same where it should change, points to a rule from this list that is missing.
In short
- Store moments in UTC and write the rule down.
- Keep calendar dates such as birthdays and invoice dates as plain dates.
- Decide, report by report, whose day a "day" is.
- Tie cut-off times and appointments to the place they belong to.
- List scheduled jobs with the local time each one should run at.
- Store time zones by name, never as fixed offsets.
- Show the time zone whenever the reader might be elsewhere.
None of this needs a special product. It needs a few decisions made before the first table is created, while they still cost a conversation rather than a migration.
When we build web software for companies that sell across borders, these date and time rules are among the questions we settle with the client before the database is designed.
Our work on this: Web Development
Planning a project like this?
Plan it in 10 steps