日期区间的终点是用第二天的 00:00:00 还是当天的 23:59:59 比较好?

[xubingok]

跟后端对接口,发现关于日期区间的定义有点模糊.

比如查询昨天的数据,我们一般是传起始时间点. 对接后端 A 的参数是:

{
    startTime:2024-01-04 00:00:00,
    endTime:2024-01-04 23:59:59
}

对接后端 B 的参数是:

{
    startTime:2024-01-04 00:00:00,
    endTime:2024-01-05 00:00:00
}

后端 A 说他用的是小于等于,后端 B 说他用的是小于,前端的时间工具类还得写两个方法...

想统一,但感觉两种方式都有自己的道理. 个人是倾向于 00:00:00 这种,可能是来源于数组截取时顾头不顾尾的概念. 另一位后端大佬则觉得 23:59:59 更便于理解.

不知道大家都是用哪种呢?

感谢大家的观点.
最终决定了用 23:59:59.

主要原因就是前端界面上必须是 23:59:59,用 00:00:00 会让用户看不懂.

为啥不用时间戳:

1.我们没有国际化需求,也没有时区需求.

2.为了后端接口的可复用性.快捷时间范围查询的参数构建由前端来完成.

会不会漏掉 59s-00s 之间的数据?

是有可能的.后端开发说他们会转成 23:59:59:99 这样的数据.

[dode]

{
startTime:2024-01-04 00:00:00,
endTime:2024-01-05 00:00:00
}
这样好，底层还有纳秒，
不然会丢失最后一秒数据

2024-01-04 23:59:59 =》 2024-01-04 23:59:59:0

2024-01-04 23:59:59:0 - 2024-01-04 23:59:59:999

前闭区间后开区间

[jrtzxh020]

想起前段时间我们老板非要要求整个 24:00 出来，时间选择控件都要有。。

[fkdog]

流量大的站点用户卡在 23:59:59.5 秒来访问，那就筛查不到了。
数学没学好的喜欢用 23:59:59 ，极限懂得伐？

[MaxChow]

其实都可以的，主要看你对数据精度的要求～
如果是毫秒级别的，当然是用 `小于 次日 00:00:00`，要不然就会丢失 59 秒至后的数据～
所以个人认为综合后最佳的写法就是 小于 次日 00:00:00 这种，适用性最好

[xianghaolin]

00:00:00 - 23:59:59

[fionasit007]

@Huelse 所以说是一个坑，当时财务老是和我说我后台的数据和官方数据对不上，后面发现是抖音后台没按左闭右开来

[keppelfei]

理论上不会传这种格式，都是时间戳

[Ahy]

这有啥好讨论的？

[leconio]

题外话：为啥不用时区无关的时间戳呢，还锁区吗？

[Inn0Vat10n]

肯定传时间戳啊，别的不说，你这格式连时区信息都没有

[opengps]

23:59:59.9999999

[deef]

显示的时候带上秒，让用户自己判断

[mtrec]

最好的是左闭右开 就算你现在的时间精度是秒 以后需求变毫秒再改吗

[demonps]

商量好就行了呗, 但为啥不用时间戳呢?

[zhlxsh]

如果 0:00:00.000 算做这一天的开始，其他时间都是这一天内
比如
23:59:59
23:59:59.000
23:59:60
24:00:00
兼顾存在的和不存在的情况，B 方法的 2024-1-4 0:00:00 到 2024-1-5 0:00:00 更合适

[watry]

住过的小区门禁可能有相关 bug ，23:59 这一分钟刷卡不开门

[EminemW]

选 B ，显示 2023-01-01 00:00:00 - 2023-01-01 23:59:59 ，但是传的结束时间+1 秒。实际查询是 >= 2023-01-01 00:00:00 && < 2023-01-02 00:00:00

[charlie21]

在数据表中添加一个 date_id 栏位，在写入数据时候此栏位写入比如 20240131 ，在查询数据时候直接 用 sql 返回 date_id === 20240131 的所有条目（避免去读取 timestamp 栏位并做比较）

[jiangzm]

不建议前端传，如果一定要前端传应该是 23:59:59 ，这样后端比较有可能漏掉 23:59:59 001 ~ 23:59:59 999 的数据。

所以前端最好是传日期，如何比较是后端接口逻辑。

[ffgrinder]

看完这个帖子，我对这个论坛的程序员的水平又有了新的认识。

[zjp]

#120 +1 这事和时间戳没关系

[jsq2627]

unix 时间戳是最不容易出错的，不用考虑夏令时，不用考虑闰秒，不用考虑特殊时间点（比如这个 https://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-epoch-milli-times-in-year-1927-giving-a-strange-r ）

[equationzhao]

我们传的都是 nanosecond

[IvanLi127]

数据库里存的精度就决定了 A 方案是切实可行的。

我一直用 A 方案，数据库精度是毫秒所以用 ISO8601 格式传精度也固定在毫秒。

这样前端显示也方便，不用转。后端在数据切片里取数据直接截断时间文本就能当索引用。

全部闭区间，以后不用想这次接口到底哪边开哪边闭，减少脑抽时刻。

[auh]

[2024-01-05 00:00:00 ，2024-01-06 00:00:00)
[2024-01-05 00:00:00 ，2024-01-05 23:59:59:999]

[yKXSkKoR8I1RcxaS]

B 最符合常理和设计规范，做任何事不要在时间的末尾做，要在日期的下一阶段的初始做，像 59 秒、59 分、23 小时、31 日等等都要使用<00 秒 <00 分 <00 时 <01 日

[Hyvi]

这细节也要耗费这么多人的时间，定一个就行，没什么影响，就随便定一个。

[sobev]

数据库都有时间精度的吧，MySQL 中的 DATETIME 类型精度为秒（秒级），可以存储的范围为'1000-01-01 00:00:00'到'9999-12-31 23:59:59'。
那就是说 23:59:59 就是一天的结束时刻，在 23:59:59 和 00:00:00 之间数据的时间都会被具体到某一秒

[cnhongwei]

我们是前后端交互使用 A 方案，这个符合人的习惯，但后台实现使用 B 方案，后台程序查询前加一秒或一天，避免时间精度问题而漏数据。

[timpaik]

那么请问 2023 年是 2023 年 1 月 1 日到 2023 年 12 月 31 日还是 2024 年 1 月 1 日呢？
肯定是前者嘛，其他时间也同理

[06_taro]

24:00:00

[chaoyebugao]

不应该使用 23:59:59 这种，问题来自于设计上。如果你列时间精度只到秒那没问题，但是如果列有更高精度就会丢失 23:59:59 到第二天 00:00:00 之间的数据，所以，应该遵循左闭右开模式，即 x >= '2024-01-04 00:00:00' && x < '2024-01-05 00:00:00' 这种方式