<p>企业周期编号应通过整除运算计算：period_id = (ts - offset) / T，其中T为周期长度（秒），offset为Unix纪元到业务起点的秒数；无需(int)强转，避免溢出与精度问题。</p>

直接用 (int) 强转格林威治秒级时间戳（即 Unix 时间戳，单位：秒）来换算企业自定义周期因子，本质是做“向下取整的周期对齐”，关键不在强转本身，而在理解周期起始点与截断逻辑。C/C++/Java/Python（int()）等语言中，(int)ts 对非负数等价于截断小数，但时间戳通常是 long 型整数，真正需要的是 整除取商 + 周期偏移校准，而非盲目强转。

明确周期因子的数学定义

企业自定义周期如“每15分钟一个周期”“每天0点起每4小时一档”“每周一00:00起每3天为一组”，需统一表达为：

• 基础周期长度 T（单位：秒）：例如15分钟 → T = 900，4小时 → T = 14400，3天 → T = 259200
• 全局基准偏移 offset（单位：秒）：从 Unix 纪元（1970-01-01 00:00:00 UTC）到你业务周期起点的秒数。例如“每天0点起”，则 offset = 0；若周期从 2024-01-01 08:00:00 UTC 开始，则 offset = 1704096000（该时间戳）

核心换算公式（不依赖浮点，全程整数运算）

给定秒级时间戳 ts（long 类型），对应的企业周期编号（从0开始）为：

period_id = (int)((ts - offset) / T);

注意：
– 必须先减 offset，再整除 T，顺序不可逆；
– 在 C/Java 中，(ts - offset) / T 默认为向零取整（对非负数即向下取整），安全；
– Python 中 // 是地板除，同样适用；
– 无需显式 (int) 强转**，因为 ts、offset、T 都是整数，整除结果天然是整数**；强行加 (int) 对 long 型可能触发隐式降级（如 long → int 溢出），反而危险。

实战常见场景与写法示例

场景1：每30分钟一周期，当天0点起
– T = 1800，offset = ts_today_00:00（可由 ts - ts % 86400 快速得）
– period_id = (ts - (ts - ts % 86400)) / 1800 = (ts % 86400) / 1800 → 即当天第几个30分钟段（0~47）

场景2：每周一00:00起，每5天为一周期
– 先算最近周一00:00时间戳（假设 ts 是 UTC）：
 mon_00 = ts - ((ts / 86400 + 4) % 7) * 86400; // +4 因为 Unix纪元是周四，(0+4)%7=4 → 周一余数为0
– T = 5 × 86400 = 432000
– period_id = (ts - mon_00) / 432000;

避坑提醒：强转不是万能钥匙

• 对负时间戳（1970年前），C/Java 中 a/b 向零取整，Python a//b 向下取整，行为不一致 → 统一用非负 offset 设计，避免负 ts 参与运算
• 不要对浮点时间戳做 (int) 强转再计算，如 (int)(ts_float / T) —— 浮点精度丢失可能导致跨周期错误（尤其大数值时）
• 周期边界要闭环：用 period_id 反推起始时间应为 start_ts = offset + period_id * T，验证是否 ≤ ts < start_ts + T