Handling time zones and daylight saving time (DST) is one of the most common sources of errors in embedded systems. While obtaining accurate time is relatively straightforward using RTCs, GPS or NTP, converting that time into meaningful local time is often more complex than expected.
This article explains how to correctly handle UTC, time zones and DST in embedded designs.
UTC: The Foundation of All Timekeeping
Most time sources provide time in UTC (Coordinated Universal Time).
- GPS outputs UTC time
- NTP servers use UTC
- Atomic clock signals encode UTC or local variants
UTC does not include time zones or daylight saving time adjustments.
What Are Time Zones?
Time zones represent regional offsets from UTC.
- UTC-5 → Eastern Standard Time (EST)
- UTC+1 → Central European Time (CET)
These offsets must be applied in software to convert UTC into local time.
Daylight Saving Time (DST)
DST adds additional complexity by shifting the clock seasonally.
- Typically +1 hour during summer
- Start and end dates vary by region
Incorrect DST handling is a common source of bugs.
Why You Should Always Use UTC Internally
Best practice in embedded systems is to store and process time in UTC.
- Avoids ambiguity
- Simplifies synchronization
- Ensures consistency across systems
Local time should only be calculated when needed for display or user interaction.
Converting UTC to Local Time
Basic Offset Method
For simple systems, a fixed offset can be applied:
- Local time = UTC + offset
This works only if DST is not required.
With DST Handling
More advanced systems must include DST rules:
- Determine if DST is active
- Apply additional offset if needed
This requires region-specific logic.
Common DST Rules
North America
- Starts: second Sunday in March
- Ends: first Sunday in November
Europe
- Starts: last Sunday in March
- Ends: last Sunday in October
Different regions may use completely different rules or no DST at all.
Implementation Strategies
Simple Systems
- Use fixed offset
- No DST handling
Configurable Systems
- User selects time zone
- DST rules implemented in firmware
Connected Systems
- Fetch time zone data from internet
- Use libraries with built-in support
Unix Time and Epoch
Many systems use Unix time internally.
- Counts seconds since January 1, 1970 (UTC)
- Easy to calculate and store
Time zone conversion is applied when converting Unix time to human-readable format.
Common Mistakes
- Storing local time instead of UTC
- Ignoring DST transitions
- Hardcoding incorrect DST rules
- Forgetting regional differences
Best Practices
- Always store time in UTC
- Convert to local time only for display
- Use tested libraries when possible
- Allow user configuration for time zone
Example Workflow
- Get UTC time (RTC, GPS, NTP)
- Apply time zone offset
- Check DST rule
- Adjust time if needed
- Display local time
When Does It Matter?
- Clocks and displays → critical
- Data logging → important
- Internal timing only → less critical
Conclusion
Handling time zones and DST correctly is essential for any system that interacts with users or displays local time. While UTC simplifies internal processing, proper conversion is required to ensure correct real-world behavior.
By following best practices and using reliable conversion methods, you can avoid common pitfalls and build robust time-aware systems.