Reliability
The midnight bug: why a date is not a timestamp
A checkout date such as 2026-07-11 looks harmless until software interprets it as midnight in the wrong time zone.
July 2026 · 5 min read
Business systems often expose dates without times because humans naturally understand the surrounding policy. A hotel checkout date means something like 'the guest may stay until the property's checkout time.' Software does not know that unless the rule is modeled explicitly.
Parsing a date-only value into a timestamp can silently place it at midnight. Add a time-zone conversion and a credential intended to remain valid through the morning can expire hours before a guest is expected to leave.
Model the policy, not the string
A robust access window needs the property's time zone, check-in time, checkout time and any approved exceptions. The reservation date is one input to that policy, not the finished timestamp.
- Store an IANA time zone for each property.
- Model check-in and checkout times explicitly.
- Convert local wall-clock policy into UTC at system boundaries.
- Treat early arrival and late departure as explicit business states.
The broader lesson
Whenever a domain has a human interpretation of time, encode that interpretation. Dates, deadlines, trading days, reservation windows and recurring schedules all become unreliable when implicit policy is left for a parser to guess.