isPeakHour 少一个星期几判断:2026-08-23 起周末全天低谷价
- Dominant language
- TypeScript
- Stars
- 7
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
`src/pricing.ts`:
```ts
export function isPeakHour(nowMs = Date.now()): boolean {
const beijingHour = (new Date(nowMs).getUTCHours() + 8) % 24
...
}
```
只看小时。**2026-08-23 00:00(北京时间)起,DeepSeek 的高峰时段只在周一至周五**,周六周日全天按空闲时段收 —— 厂商页中文写「高峰时段为北京时间周一至周五 9:00 - 12:00、14:00 - 18:00」,英文写 "Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday"。
面板上会看到两处不对:`window` 字段在周末显示 `peak`,以及 `PEAK_PRICES` 被用在实际按 `OFF_PEAK_PRICES` 结算的那 14 个钟头上。热力图和成就那边如果按周聚合,周末两格会整体偏高一倍。
```ts
function isBeijingWeekend(ms: number): boolean {
const day = Math.floor((ms + 8 * 3600_000) / 86400_000)
const weekday = (day + 4) % 7 // 0=周日 … 6=周六
return weekday === 0 || weekday === 6
}
export function isPeakHour(nowMs = Date.now()): boolean {
if (nowMs >= Date.parse('2026-08-22T16:00:00Z') && isBeijingWeekend(nowMs)) return false
const beijingHour = (new Date(nowMs).getUTCHours() + 8) % 24
...
}
```
`2026-08-22T16:00:00Z` 就是北京时间 2026-08-23 00:00,也就是这条规则的生效时刻。这个门要留着:面板会回看历史用量,而生效之前的周末是照收高峰价的,一起减半会把过去的花费少算一半,而且方向上没人会来报错。
一个容易被绕过去的坑:**星期几要按北京时间数**。用 `getUTCDay()` 今天也能得到同样的结果,但那是巧合 —— 两个高峰窗口都在 16:00 UTC 之前结束,而 16:00 UTC 恰好是北京日历和 UTC 日历最早能分开的那一刻。哪天窗口一挪,UTC 数法每周就错 16 小时(周五和周日的 16:00–24:00 UTC)。
`test/unit/pricing.spec.ts` 要补用例的话,窗口两端、周末两头、生效时刻前后、以及两种读法分歧的那一段,我整理成了 JSON,CC0,直接拿去当夹具就行:。四种典型错法写在这里:(纯静态镜像:)。
---
**补记(当天晚些时候):这条现在能自己复跑。** 向量那边加了个零依赖跑测器,Node 16+:
```
git clone https://github.com/xyzs996/deepseek-peak-hours && cd deepseek-peak-hours
node conformance/run.mjs --detail
```
它按 commit 抄了九个 DSH 计费插件的判峰函数各一份。`dsh-board@8f5b962` 是 **9/12**,挂在这三个:
```
2026-08-23T01:30:00Z 周日 09:30 应为 offpeak,得到 peak
2026-08-23T07:00:00Z 周日 15:00 应为 offpeak,得到 peak
2026-08-29T02:00:00Z 周六 10:00 应为 offpeak,得到 peak
```
另外三条跑不了:它们走一份合成时段(高峰窗口 16:00–22:00 UTC),而这里窗口写死在 `isPeakHour` 里,从外面指不过去。那三条抓的正是「星期几读错日历」,所以这个轴现在测不到。
顺带说一句:`EFFECTIVE_AT_MS = Date.UTC(2026, 7, 16, 16)` 加上 `currentRate` 里那道 `standard` 分支,是这九个里做得最干净的一处——多数插件根本没有生效闸,回补历史账单时会把峰谷价套到还没开始峰谷计价的日子上。周末这条新规也需要同样一道闸,时刻是 `2026-08-22T16:00:00Z`,在你这儿刚好就是加第二个常量的事。
抄错了算我的账:说一声我改了重跑。
---
九个项目的成绩、各自挂在哪几个时刻,都在这一页,能自己复跑:。改好了在那儿说一声,当天重跑更新;要是我把你的判峰函数抄错了,那是我这边的账,也在那儿改。
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with src/pricing.ts and trace the isPeakHour callers that drive the window, billing, heatmap, and achievement data. Run test/unit/pricing.spec.ts, using the supplied conformance fixtures for weekend boundaries, the 2026-08-22T16:00:00Z cutoff, and Beijing-versus-UTC weekday differences. Done means historical pre-cutoff weekends retain peak behavior while later weekends and affected displays use off-peak pricing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- analytics, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 74/100