Our booking form displays available slots in the user's local time, while the backend stores UTC. A customer selecting 9:00 sometimes sees 10:00 in confirmation around a daylight-saving transition. We're clearly mixing timezone-free strings with actual instants somewhere. I'm thinking: store timestamp plus the business's IANA timezone, convert only at the edges, and test ambiguous local times. What is your practical test checklist for this class of bug?
Dealing with date and timezone bugs in a booking interface
- webdev
- date
- timezone
- bugs
40
4 replies
I’d test both DST directions, not just the one your users complained about. Spring forward and fall back cause different kinds of pain. Then...
I’d test both DST directions, not just the one your users complained about. Spring forward and fall back cause different kinds of pain. Then I’d verify the full round trip: selected slot, stored value, displayed confirmation, and any edit screen.
Also check what happens when the user’s timezone is different from the business timezone. People often fix the DST bug and still break the “same city, different zone” case. That one is quieter until it isn’t.
We do have customers in multiple zones, so that’s a fair point. I was mostly focused on the daylight-saving jump because that’s when the mis...