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