Timezone Bugs in AI-Generated Booking Systems: A Case Study

A developer built a booking system prototype for a tutoring platform ($12k MRR) using Claude in 5 hours. Deployed immediately, it generated 89 bookings in 2 weeks. But a timezone bug caused 11 bookings at wrong times, eroding tutor trust.

The Bug

The original implementation stored all times in UTC and displayed them in the server's timezone (IST). Tutors in other timezones saw incorrect available slots. A tutor in Dubai reported: "My student booked for 3pm but showed up at 4:30pm" — the 1.5-hour offset matched the IST-to-GST difference.

Attempted Fixes

First attempt: Claude generated a fix using the user's browser timezone. It worked for IST and GST, but broke for US timezones due to daylight saving time transitions.

Second attempt: The developer requested using a timezone library — luxon. Implemented correctly, it worked across all tested zones.

Lessons

• Prototypes that work for your timezone and test cases will break for others.
• Claude confidently generates incorrect timezone handling — always test across at least 3 timezone regions before deploying scheduling features.
• Now at 142 bookings/month, but the 11 wrong-time bookings cost trust with tutors who had to apologize to students.

Speed from AI coding agents doesn't remove the developer's responsibility for edge-case testing.