Storing Dates, Times and Time Zones
Dates and times look simple but quietly cause some of the most stubborn bugs in software — a report off by an hour, a booking on the wrong day, or a deadline that shifts in summer. Handling them properly from the start avoids a great deal of confusion.
This article explains the approach we take so your timestamps are always correct, wherever your users are.
Store in UTC, Display Locally
The golden rule is to store every timestamp in a single neutral time zone — Coordinated Universal Time (UTC) — and convert to the viewer's local time only when displaying it. This keeps the stored data unambiguous.
Why Time Zones Are Tricky
- Daylight saving means UK clocks shift twice a year.
- Users in different countries see the same event at different local times.
- Some dates (like a birthday) have no time zone at all and should be stored as a plain date.
Getting It Right
We separate true moments in time (stored in UTC) from calendar dates (stored as dates), and we keep time-zone conversion at the edges of the system. This keeps your scheduling, reporting and reminders dependable.
Frequently Asked Questions
Why not just store UK time?
Because daylight saving creates ambiguous and missing hours twice a year. UTC has no such gaps, so it is always safe.
If you need a hand with any of this, your Progressive Robot delivery team is ready to help. Raise a ticket from the Support area of your client portal or speak to your account manager and we will guide you through the next steps.