dfkai / dfkai/dsh-board

周末全天空闲价(今天生效):isPeakHour 少了星期这一维,成本读数翻倍

Open Beginner friendly
#2 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
7
Forks
2
PR merge metrics
No merged PRs in 30d

Description

`isPeakHour`(`src/pricing.ts:47`)只看北京时间的小时数,所以今天(2026-08-23,周日)09:00 起会判成高峰,而 DeepSeek 今天全天按空闲价计费——侧栏成本面板会显示成实际账单的两倍。

官方原文([定价页](https://api-docs.deepseek.com/zh-cn/quick_start/pricing/),2026-08-22 读取):

> Effective 00:00 (Beijing Time) on Sunday, August 23, 2026, we will adjust our peak/off-peak billing rules, with off-peak rates applying throughout the day on weekends.

换算成 UTC 是 `2026-08-22T16:00:00Z`。峰段窗口本身是对的,缺的是星期这一维。

`EFFECTIVE_AT_MS` 那道闸的形状正好可以照搬一遍:再加一个 `WEEKEND_EFFECTIVE_AT_MS = Date.UTC(2026, 7, 22, 16)`,让周末分支只在这个时刻之后生效。这一层不能省——`priceFor` 是拿 `nowMs` 定价的,历史用量重算传进来的是当时的时刻,无条件打折会把 8 月之前那些周末的账悄悄改小。

**有一处特别容易踩空:** 现在的 `(new Date(nowMs).getUTCHours() + 8) % 24` 只取了小时、没有进位到日期,所以顺手补一个 `new Date(nowMs).getUTCDay()` 的话,星期几和小时数来自两个不同的时刻。北京的周末是从周五 16:00 UTC 到周日 16:00 UTC,两份日历只在 16:00–24:00 UTC 这一段对不上,而这两个峰段窗口都不在那一段里——**用官方窗口写得出来的用例全都能过**,等哪天官方把窗口挪过 16:00 UTC 才开始出错。让两者出自同一个平移过的时刻即可:

```ts
const bj = new Date(nowMs + 8 * 3600e3)
const hour = bj.getUTCHours()
const dow = bj.getUTCDay()
```

`describeWindow` 那一侧也要跟着走:周末两侧都是空闲档,周五傍晚之后的下一次真正切换是周一 09:00(六十多小时之后),照旧返回当天的下一个边界等于承诺一个不会发生的切换。

可以钉的时刻:

| 时刻 (UTC) | 北京时间 | 应判 |
|---|---|---|
| `2026-08-23T01:30:00Z` | 周日 09:30 | offpeak |
| `2026-08-23T07:00:00Z` | 周日 15:00 | offpeak |
| `2026-08-24T01:30:00Z` | 周一 09:30 | peak |
| `2026-08-22T01:30:00Z` | 周六 09:30(生效前) | peak |
| `2026-08-28T16:30:00Z` | 周六 00:30(UTC 还是周五) | offpeak |

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in src/pricing.ts at isPeakHour and inspect priceFor plus describeWindow. Use the pinned UTC times in the issue as regression cases, checking the shifted Beijing date and the weekend effective timestamp. Done means weekend off-peak pricing starts only after the stated timestamp, historical pricing remains unchanged, and describeWindow reports the next real boundary.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
82/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.