1eaa203eba2cbf41e47d57345961ca99b38020f7
问题 ---- process_return 与 scrap_sources.deduct 原先用 datetime.now()(容器本地时间, Docker 默认 UTC)写 return_time / operation_time,而同一行的 borrow_time 由 beijing_time() 写入 —— 同一行两个时钟,差 8 小时。 实测(开发库)trans_borrow 有 53 行呈现「归还时间早于借出时间」这种物理上 不可能的数据,例如 id=80 借出 09-09 11:04、归还 09-09 03:46。 代码侧已修(f7c49f4),新数据已是北京时间 —— 本次只处理存量。 ★ 脚本刻意做了「先自检、后修正」的两段式 服务器 API 容器的 TZ 未必是 UTC(若本就是 Asia/Shanghai,datetime.now() 一直是北京时间,则**根本无需修正**)。若不做自检直接 +8h,会把正确的时间 改错。故第 0 步先输出:异常行数、以及按分界切出的「UTC 段/空档/北京段」 三段计数,由使用人据结果决定是否执行第 2 步。 ★ 分界与幂等性都在脚本里写明 · 分界 = 修复代码在该服务器**部署生效的时刻**(不是提交时刻),需按实际调整; · 脚本**不幂等** —— 重复执行会再加 8 小时,已显式警示并给出回滚写法。 开发库已按此逻辑修正:53 行 trans_borrow + 1 行 trans_scrap, 修正后「归还早于借出」为 0,抽样时间落在正常工作时段。
Description
No description provided
Languages
Python
70.2%
CSS
14.9%
Vue
7.6%
HTML
4.2%
TypeScript
3.1%