Skip to content
Build in Public

An 11pm rabbit hole: timezones in availability

Two posts in one day. I'm flagging that honestly, because the whole point of doing this in public is to show the real rhythm, and the real rhythm is: some days…

SD
Shubham Datarkar
· 3 min read
Updated

Two posts in one day. I'm flagging that honestly, because the whole point of doing this in public is to show the real rhythm, and the real rhythm is: some days nothing, some days you can't stop. Today I couldn't stop. The ice cream wore off, everyone went home, and I sat back down to build what I thought was a quick, pleasant feature. Three hours later it was past 11 and I was arguing with the concept of time itself.

The feature: availability. A host needs to tell the system when they're free. "I take bookings Monday to Friday, 10 to 6." Then guests should only ever see those open slots. Sounds like an afternoon's work. Famous last words.

I started with the data model, and I'm actually happy with where it landed. A host's weekly schedule gets stored as structured data — each day, the windows they're open. On top of that, blocked dates, for the one-off "I'm away on the 20th." And buffer minutes between bookings, so a host isn't slammed into a back-to-back-to-back day with no breath between sessions. That last one came straight from watching real hosts on the PHP version burn out because the software happily booked them solid. Small feature, big kindness.

Then I built the part that turns all that into actual bookable slots — take the weekly schedule, subtract the existing bookings, subtract the blocked dates, respect the buffers, and hand the guest a clean list of times they can pick. Got it working. Felt great. Tested it. Looked perfect.

And then the rabbit hole opened, and its name was timezones.

Here's the trap, and it's a famous one that every developer falls into exactly once: I was storing and showing times without being careful about whose time they were. "10 AM" is meaningless on its own. 10 AM where? A host in India sets their hours in their time. A guest could be looking at that page from anywhere. If I'm sloppy, the host says "I'm free at 10 AM," and a guest somewhere else sees a different number entirely, books what they think is 3 PM, and shows up at a time the host never offered. Nobody did anything wrong, and yet the booking is just... wrong. Quietly,

confidently wrong. The worst kind of bug, because it doesn't crash — it just betrays people politely.

I went deep. Down into the genuinely brain-bending territory where you stop trusting what "10 AM" even means and you start drawing diagrams. The thing that makes timezones so nasty is that the code looks right. The numbers look right. It only breaks when two people in two places look at the same slot, which is exactly the situation you don't test when you're one tired guy on one laptop at 11 PM.

The decision I landed on: default everything to IST, because that's who Book A Sloth is for right now — Indian creators and their clients — but store times carefully enough that I'm never just trusting a naked number. Be correct now, so that the day I expand beyond one timezone, I'm not unwinding a disaster. I didn't fully solve world-time tonight. I solved "don't lie to people about when their booking is," which is the part that actually matters at this stage. Knowing where the deep problem lives, and walling it off cleanly, is sometimes the win — not slaying it entirely at midnight.

I finally looked up and it was past 11. I'd gone in for a quick feature and come out having quietly rebuilt my understanding of time. That's the rabbit hole. You don't choose them. You just look up and realize you're at the bottom of one.

But the availability engine works now. A host sets their hours, blocks a date, gets their buffers — and guests see the right slots, in the right time, with no quiet betrayals.

Worth the late night. Most of them are. Not all. Tomorrow's wasn't — tomorrow the whole booking flow starts silently creating garbage, and that one I did not enjoy.

by Shubham DatarkarBuild in Public

Reactions

How was this article?

Newsletter

Never miss the next one

Get the latest playbooks, build logs, and the occasional unpublished idea straight to your inbox. One signal a week — no noise.