Does your DeepSeek cost code read the weekday off the shifted clock?

[xyzs996]

DeepSeek's weekend rule took effect today: off-peak rates now apply all day Saturday and Sunday, on top of the weekday windows. The interesting part isn't the rule, it's that the two published versions of it don't say the same thing.

The English pricing page: "Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday." The Chinese page: 「高峰时段为北京时间周一至周五 9:00 - 12:00、14:00 - 18:00」. The hours agree. The calendar doesn't — one pins the weekday to Beijing time, the other attaches UTC to the hours and leaves the weekday unqualified. Read in English, it says UTC weekdays, and the two readings differ over 16:00–24:00 UTC on Friday and on Sunday.

And with the current windows, nothing catches it. Both peak windows sit clear of 16:00–24:00 UTC, so both calendars produce identical prices at all 168 hours of the week. Code written from the English sentence passes every test you can write against the published schedule, and starts being wrong about money the day a window moves past 16:00 UTC.

I read the pricing function of 19 DeepSeek cost/usage plugins, gateways and price catalogues on the day the rule landed. Four had the calendar axis right. One had the machinery right and the shipped default config stale. Fourteen split between an hour-only branch (bills a weekend call at 2×) and — in two of the config-driven ones — a schema with no weekday dimension at all, where the rule cannot be expressed no matter how the code is written.

So, the question, and I'd genuinely like to know rather than guess:

• What does your code return for 2026-08-28T16:30:00Z? That's Friday 16:30 UTC = Saturday 00:30 Beijing. Off-peak is the correct answer; peak means the weekday is being read off the unshifted instant.
• Can your pricing config even express "weekday"? If the schedule is a list of hour ranges, adding the day-of-week dimension is a schema change, and those are much cheaper before a config format ships than after.

The rule in prose, with both language versions quoted and every rate re-read daily: https://xyzs996.github.io/llm-api-pricing/deepseek-peak-hours.html
Dated vectors including the two discriminating instants, CC0: https://github.com/xyzs996/deepseek-peak-offpeak-vectors

One thing this piece could not settle: whether anyone plans around it. Before reading this, did you know DeepSeek's peak rate stops at the weekend? Reply with yes or no — a no is the answer that tells me this page is worth keeping.