Abhay Pratap Mishra
@abhay • 1 days ago
A debugging prompt that makes the AI rank hypotheses, name a confirming experiment and only then propose a minimal fix with a regression test.
symptomexpectedcodetried{{symptom}}{{expected}}{{code}}{{tried}}symptom: Orders placed between midnight and 5:30am IST show up under the previous day in the daily sales report.
expected: Each order is counted on the calendar day it was placed in India.
code:
```ts
// report/groupOrders.ts
type Order = { id: string; createdAt: string; amount: number } // createdAt e.g. "2026-09-23T20:15:00Z"
export function groupOrdersByDay(orders: Order[]) {
const buckets: Record<string, Order[]> = {}
for (const order of orders) {
const day = new Date(order.createdAt).toISOString().slice(0, 10)
;(buckets[day] ??= []).push(order)
}
return Object.entries(buckets)
.sort(([a], [b]) => a.localeCompare(b))
.map(([day, items]) => ({
day,
count: items.length,
total: items.reduce((s, o) => s + o.amount, 0),
}))
}
```
tried: Checked the DB timestamps are correct (stored in UTC with Z). Setting TZ=Asia/Kolkata on the server changed nothing.2026-09-23T19:40:00Z) is bucketed under 2026-09-23 instead of 2026-09-24.toISOString() always renders UTC (line 7). IST is UTC+5:30, so every order from 00:00 to 05:29 IST has a UTC date one day earlier. The window you describe is exactly the size of the offset. That's the tell.createdAt sometimes lacks the Z. new Date("2026-09-23T19:40:00") is parsed as local time, which would shift days on some rows. It's less likely, because you confirmed the stored values carry Z.day. new Date("2026-09-24") is UTC midnight. Rendered in IST that's still the 24th, so this can't produce your symptom. It would only matter for users west of UTC.TZ=Asia/Kolkata changing nothing supports hypothesis 1: toISOString() ignores the process timezone entirely. Hypothesis 2 is ruled out by your DB check.`bash`2026-09-23, although the order is on the 24th in India. If it prints 2026-09-24, I'm wrong and I'd need to see how the report calls this function.`diff``ts`2026-09-23) and passes after the fix. If you'll ever report for other regions, pass the timezone in as a parameter instead of hard-coding it.grep -rn "toISOString().slice(0, 10)" and .split("T")[0]DATE(created_at) or created_at::date running in a UTC sessionnew Date().setHours(0,0,0,0) on a UTC serverTZ change failing is what confirms the diagnosis. The fails-before, passes-after test makes the fix verifiable, and step 6 turns a single fix into a codebase-wide sweep.