Do you really need UTC times everywhere?

Posted: (EET/GMT+2)

 

There is a common rule in software development: store all your timestamps in UTC.

It is a good rule for many systems, but it should not be followed blindly. UTC is very useful when your application needs a single, unambiguous timeline. For example:

  • global SaaS applications
  • systems used across multiple time zones
  • distributed logs and telemetry
  • queues and integration events
  • APIs shared between different organizations.

In those cases, UTC avoids many problems. Events can be compared and ordered without asking which local time zone was used.

But not every application is a global distributed system used by thousands of users all over the globe.

If you are building an internal application for one company in one location, local business time may be the more useful value.

For example, consider a SQL Server table with a normal audit column:

SELECT Id, CreatedAt
FROM Orders
ORDER BY CreatedAt DESC;

If CreatedAt is stored in UTC, every direct database query shows a value that needs (mental) conversion before it is meaningful to local users, support staff, or developers.

The same conversion then appears in many places:

  • admin screens
  • CLI tools
  • reports
  • exports
  • quick SQL queries during troubleshooting.

If the business only operates in one time zone, this may add complexity without much benefit.

However, even if this is the case, it's worth separating technical time from business time.

Technical timestamps are often good candidates for UTC:

  • application logs
  • distributed traces
  • message queue timestamps
  • cross-system integration events
  • security and audit events crossing system boundaries.

Business timestamps may be different:

  • order creation time shown to local staff
  • work shift start time
  • invoice date
  • delivery date
  • local reporting date
  • appointment time in one known location.

For these values, local time can be easier to read and easier to support.

The main caveat is daylight saving time (DSR). Local time can be ambiguous when clocks move backwards, and missing when clocks move forwards.

If exact ordering around daylight saving time matters, store UTC or use DateTimeOffset so the offset is preserved.

One practical approach is:

  • use UTC for technical events and distributed systems
  • use local business time for local business concepts
  • use DateTimeOffset when the offset matters
  • document the decision clearly in the database and code -- good naming goes a long way.

The important part is not choosing UTC or local time as a religion. The important part is knowing what the timestamp means.

UTC is a tool, not a rule. Use it when the system needs global, unambiguous time. For local business applications, local time can sometimes be the simpler and more useful choice.