日期区间的终点是用第二天的 00:00:00 还是当天的 23:59:59 比较好?
xubingok · 2024-01-05 09:23:10 +08:00 · 17772 次点击这是一个创建于 392 天前的主题，其中的信息可能已经有所发展或是发生改变。
跟后端对接口,发现关于日期区间的定义有点模糊.
比如查询昨天的数据,我们一般是传起始时间点. 对接后端 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 更便于理解.
不知道大家都是用哪种呢?
第 1 条附言 · 2024-01-08 09:50:31 +08:00
感谢大家的观点.
最终决定了用 23:59:59.
主要原因就是前端界面上必须是 23:59:59,用 00:00:00 会让用户看不懂.
为啥不用时间戳:
1.我们没有国际化需求,也没有时区需求.
2.为了后端接口的可复用性.快捷时间范围查询的参数构建由前端来完成.
会不会漏掉 59s-00s 之间的数据?
是有可能的.后端开发说他们会转成 23:59:59:99 这样的数据.
最终决定了用 23:59:59.
主要原因就是前端界面上必须是 23:59:59,用 00:00:00 会让用户看不懂.
为啥不用时间戳:
1.我们没有国际化需求,也没有时区需求.
2.为了后端接口的可复用性.快捷时间范围查询的参数构建由前端来完成.
会不会漏掉 59s-00s 之间的数据?
是有可能的.后端开发说他们会转成 23:59:59:99 这样的数据.
132 条回复 • 2024-01-08 12:25:04 +08:00
 |
101
dode 2024-01-05 15:55:51 +08:00
{
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 前闭区间后开区间 |
 |
102
jrtzxh020 2024-01-05 16:16:56 +08:00
想起前段时间我们老板非要要求整个 24:00 出来，时间选择控件都要有。。
|
 |
103
fkdog 2024-01-05 16:59:41 +08:00
流量大的站点用户卡在 23:59:59.5 秒来访问，那就筛查不到了。
数学没学好的喜欢用 23:59:59 ，极限懂得伐？ |
 |
104
MaxChow 2024-01-05 17:26:02 +08:00
其实都可以的，主要看你对数据精度的要求～
如果是毫秒级别的，当然是用 `小于 次日 00:00:00`，要不然就会丢失 59 秒至后的数据～ 所以个人认为综合后最佳的写法就是 小于 次日 00:00:00 这种，适用性最好 |
 |
105
xianghaolin 2024-01-05 17:30:33 +08:00
00:00:00 - 23:59:59
|
 |
106
fionasit007 2024-01-05 17:36:49 +08:00
@Huelse 所以说是一个坑，当时财务老是和我说我后台的数据和官方数据对不上，后面发现是抖音后台没按左闭右开来
|
 |
107
keppelfei 2024-01-05 17:59:31 +08:00
理论上不会传这种格式，都是时间戳
|
 |
108
Ahy 2024-01-05 18:20:50 +08:00
这有啥好讨论的？
|
 |
109
leconio 2024-01-05 18:46:59 +08:00 via iPhone
题外话：为啥不用时区无关的时间戳呢，还锁区吗？
|
 |
110
Inn0Vat10n 2024-01-05 19:00:31 +08:00
肯定传时间戳啊，别的不说，你这格式连时区信息都没有
|
 |
111
opengps 2024-01-05 19:15:22 +08:00
23:59:59.9999999
|
 |
112
deef 2024-01-05 19:22:00 +08:00
显示的时候带上秒，让用户自己判断
|
 |
113
mtrec 2024-01-05 19:30:53 +08:00 via Android
最好的是左闭右开 就算你现在的时间精度是秒 以后需求变毫秒再改吗
|
 |
114
demonps 2024-01-05 19:41:01 +08:00
商量好就行了呗, 但为啥不用时间戳呢?
|
 |
115
zhlxsh 2024-01-05 19:47:24 +08:00 via iPhone
如果 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 更合适 |
 |
116
watry 2024-01-05 22:05:29 +08:00  1
住过的小区门禁可能有相关 bug ，23:59 这一分钟刷卡不开门
|
 |
117
EminemW 2024-01-05 23:05:36 +08:00
选 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
|
 |
118
charlie21 2024-01-05 23:10:26 +08:00 via Android
在数据表中添加一个 date_id 栏位，在写入数据时候此栏位写入比如 20240131 ，在查询数据时候直接 用 sql 返回 date_id === 20240131 的所有条目（避免去读取 timestamp 栏位并做比较）
|
 |
119
jiangzm 2024-01-05 23:13:42 +08:00
不建议前端传，如果一定要前端传应该是 23:59:59 ，这样后端比较有可能漏掉 23:59:59 001 ~ 23:59:59 999 的数据。
所以前端最好是传日期，如何比较是后端接口逻辑。 |
 |
120
ffgrinder 2024-01-06 00:15:02 +08:00 1
看完这个帖子，我对这个论坛的程序员的水平又有了新的认识。
|
 |
121
zjp 2024-01-06 00:32:23 +08:00
#120 +1 这事和时间戳没关系
|
 |
122
jsq2627 2024-01-06 01:32:33 +08:00
unix 时间戳是最不容易出错的，不用考虑夏令时，不用考虑闰秒，不用考虑特殊时间点（比如这个 https://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-epoch-milli-times-in-year-1927-giving-a-strange-r ）
|
 |
123
equationzhao 2024-01-06 01:39:23 +08:00
我们传的都是 nanosecond
|
 |
124
IvanLi127 2024-01-06 01:50:34 +08:00 via Android
数据库里存的精度就决定了 A 方案是切实可行的。
我一直用 A 方案，数据库精度是毫秒所以用 ISO8601 格式传精度也固定在毫秒。 这样前端显示也方便，不用转。后端在数据切片里取数据直接截断时间文本就能当索引用。 全部闭区间，以后不用想这次接口到底哪边开哪边闭，减少脑抽时刻。 |
 |
125
auh 2024-01-06 03:01:09 +08:00
[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] |
 |
126
yKXSkKoR8I1RcxaS 2024-01-06 09:20:28 +08:00
B 最符合常理和设计规范，做任何事不要在时间的末尾做，要在日期的下一阶段的初始做，像 59 秒、59 分、23 小时、31 日等等都要使用<00 秒 <00 分 <00 时 <01 日
|
 |
127
Hyvi 2024-01-06 09:35:54 +08:00
这细节也要耗费这么多人的时间，定一个就行，没什么影响，就随便定一个。
|
 |
128
sobev 2024-01-06 09:49:30 +08:00
数据库都有时间精度的吧，MySQL 中的 DATETIME 类型精度为秒（秒级），可以存储的范围为'1000-01-01 00:00:00'到'9999-12-31 23:59:59'。
那就是说 23:59:59 就是一天的结束时刻，在 23:59:59 和 00:00:00 之间数据的时间都会被具体到某一秒 |
 |
129
cnhongwei 2024-01-06 10:20:00 +08:00
我们是前后端交互使用 A 方案，这个符合人的习惯，但后台实现使用 B 方案，后台程序查询前加一秒或一天，避免时间精度问题而漏数据。
|
 |
130
timpaik 2024-01-06 20:39:47 +08:00
那么请问 2023 年是 2023 年 1 月 1 日到 2023 年 12 月 31 日还是 2024 年 1 月 1 日呢？
肯定是前者嘛，其他时间也同理 |
 |
131
06_taro 2024-01-07 14:27:12 +08:00
24:00:00
|
 |
132
chaoyebugao 2024-01-08 12:25:04 +08:00
不应该使用 23:59:59 这种，问题来自于设计上。如果你列时间精度只到秒那没问题，但是如果列有更高精度就会丢失 23:59:59 到第二天 00:00:00 之间的数据，所以，应该遵循左闭右开模式，即 x >= '2024-01-04 00:00:00' && x < '2024-01-05 00:00:00' 这种方式
|
Select Language