Handling Date and Time in Distributed Systems
Handling date and time seems simple until you work across countries, devices or distributed systems. Real systems face common problems:
Meeting booked for 7 PM in New York becomes 12:30 AM in India, which causes reminders and schedules to trigger at the wrong time. Using LocalTime.now() on different servers produces different results, so scheduled tasks run at different hours across regions.
These inconsistencies happen due to timezone assumptions and storing date and time incorrectly.
What is UTC
UTC stands for Coordinated Universal Time. It is the global reference time. Every other timezone is defined as an offset from UTC. For example:
India (IST) is UTC + 05:30
New York varies between UTC –05:00 and UTC –04:00
Dubai is UTC + 04:00
UTC does not change with daylight saving or seasons, which makes it the most reliable format for storing time in distributed systems.
What is epoch and how milliseconds are calculated
Epoch time represents the number of milliseconds (or seconds) since:
January 1, 1970 00:00:00 UTC
Examples:
0 = 1970-01-01 00:00 UTC
1,000 milliseconds = one second after epoch
When a date and time is converted to epoch:
It is first interpreted in the correct timezone
Converted into UTC
Measured as milliseconds from the epoch start
This number is global. It represents the same instant everywhere, regardless of timezone.
Always Store Time in UTC
The most reliable approach in distributed systems is to store and process timestamps in UTC.
Recommended formats:
epoch milliseconds
epoch seconds
Instant
TIMESTAMP WITH TIME ZONE
UTC ensures that the same instant in time is interpreted consistently by every system and user, regardless of location.
Convert Only at the Boundaries
Store and compute using UTC in the backend and database. Convert to local time only when displaying on:
UI
Notifications
Reports
Logs
This ensures that:
India, Dubai, New York and London see the correct local time
The stored data remains stable and unambiguous
Java APIs for Reliable Date and Time
Use the modern java.time classes:
Instant
ZonedDateTime
ZoneId
LocalDate
LocalTime
OffsetDateTime
These types preserve timezone and instant information and prevent common bugs.
Avoid the older APIs (Date, Calendar, SimpleDateFormat) in new applications.
Recommended Pattern
Convert user’s local date and time to UTC.
Store the timestamp in UTC in the database.
Convert back to the user’s timezone when presenting.
Do not store LocalDateTime without context in the database, because it loses timezone meaning.
Benefits of Storing in UTC
Prevents mismatches across regions
Eliminates daylight saving issues
Keeps scheduled tasks aligned across servers
Makes sorting and comparison safe
Works well with microservices and distributed systems
Summary
UTC is the universal reference for time. Epoch milliseconds measure time as the number of milliseconds since 1 January 1970 UTC. When you store everything in UTC and use the modern Java date and time classes (Instant, ZonedDateTime, ZoneId, OffsetDateTime), your application stays consistent and predictable across time zones, deployments and environments.
- Written by Sameer Shaikh enhanced by LMArena.
Thank you!!
