Günlük hedefimi 16:00'da %95 görüyordum, kasada %112 vardı — JavaScript setHours yüzünden UTC+3 operatörümün hedef penceresi 3 saat kaymıştı

İstanbul Kadıköy'de 34 yaşında bistro işletmecisi Aylin, Salı 16:00'da dashboard'da "%95 → ₺2.375" görüyor ama kasa toplam ₺2.806 (%112). 17 yüzdelik puan fark — altı aydır panele göre akşam servisi kararı veriyordu. Forensic: `apps/web-admin/src/app/[locale]/dashboard/goals/GoalsClient.tsx:53-63` `start.setHours(0,0,0,0).toISOString()` yapıyordu — `setHours` LOCAL TZ, UTC+3 Aylin için "bugün 00:00 İstanbul" = "dün 21:00 UTC", `.toISOString()` UTC'ye çevirince `starts_at: dün 21:00 UTC` — server UTC ile filtreliyor → panel UTC günü kapsıyor ama operatörün mental modeli İstanbul günü bekliyor → %12 misattribution (akşam servisi gece yarısı geçince DÜN günü olarak sayılıyor). **PR #651 batch VII F3** fix: `setUTCHours(0,0,0,0)` + `setUTCDate/getUTCMonth` variants. Client UTC-aligned boundary yazıyor; matematik artık tutarlı. Per-restaurant TZ (`restaurant.timezone` IANA TZ database) tam çözüm — operator "kendi günü"nü görsün diye — follow-up larger refactor. Pattern: JavaScript Date API'sinin 18 LOCAL + 18 UTC method paralel; UTC-canonical SQL filter'a flow eden her boundary UTC variant kullanmak ZORUNDA.

İlgili makaleler