Repository navigation
test(models): pin the off-peak day to the vendor clock, not UTC - #3776
Conversation
Every existing case in helpers.spec.ts passes with utcOffsetMilliseconds set to 0. Both peak windows sit before 16:00Z, and a UTC date and a Beijing date only disagree from 16:00Z onward, so with DeepSeek's real windows the two calendars price all 168 hours identically. The four new cases use a window that reaches past 16:00Z -- the only shape that separates them. Dropping the offset reddens exactly the two instants that straddle a Beijing midnight and leaves the two controls green.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. WalkthroughAdded regression tests for ChangesTimezone pricing regression coverage
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This PR adds localized regression coverage without changing production behavior; no actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Closes the first half of #3775.
resolveTimeBasedPricingappliesutcOffsetMinutesbeforegetUTCDay(), which is right — but no test inhelpers.spec.tscan tell that apart from dropping the offset entirely. SetutcOffsetMillisecondsto0and the whole file still passes.The reason is that both peak windows (
[1,4],[6,10]) sit before 16:00Z, and a UTC date and a Beijing date only disagree from 16:00Z onward. With DeepSeek's real windows the two calendars price all 168 hours identically, so no instant taken from them can discriminate. The existing weekend cases are both at02:00Z, which is the same weekday on either clock.This adds four cases on a mapping whose window reaches past 16:00Z, which is the only shape that separates them:
2026-08-28T15:00:00Z2026-08-28T16:00:00Z2026-08-30T15:00:00Z2026-08-30T16:00:00ZTest-only; no behaviour change. Dropping the offset in the implementation reddens exactly rows 2 and 4 and leaves the two controls green.
One correction to #3775 while I'm here: the four instants I listed there were all off-peak by the hour, so they return off-peak either way and do not in fact discriminate. The synthetic late window used here is what does. I'll fix that comment on the issue.
The second half of #3775 — no effective-from on
offPeakDays, so a pre-2026-08-23 weekend timestamp gets today's discount — is untouched here.Summary by CodeRabbit