为什么要用毫秒值的形式存储日期时间?

2019-04-01 15:38:46 +08:00
 5ispy

哪位帮忙解答一下,实际工作中在哪种情况下,很有必要把时间转换成毫秒值进行存储?

比如某条数据的创建时间,查询的时候不论是程序里还是写 sql 查询还需要转换,很不方便啊,为什么还要用这种数值的存储方式?比存日期类型或者字符串处理速度快?节省空间?

求解答

谢谢!!!

13155 次点击
所在节点    程序员
64 条回复
sampeng
2019-04-02 00:56:06 +08:00
楼上讨论飞了…应该和 linux 什么的无关。不然 mysql 之类里面为何有个专门的日期字段…个人觉得有些是习惯,有些是跟风。我觉得都可以…上面说处理日期问题,复杂度综合来说都各有长短不相上下。因为现在的时间库都抽象的很好用了。mysql 也自带两类个互转函数。
gjquoiai
2019-04-02 01:38:06 +08:00
我从来没搞明白过时间。。_(:з)∠)_ 所以我每次都查这个。。http://taaviburns.ca/presentations/what_you_need_to_know_about_datetimes/what_you_need_to_know_about_datetimes.pdf
binux
2019-04-02 01:53:53 +08:00
不需要而额外信息就能方便地计算比较
t6attack
2019-04-02 03:29:51 +08:00
日期时间的书写格式有 N 多种,如果把语言因素也加进去,则有上百种。这么多写法,总要有一个标准。
阿拉伯数字人类共通,作为标准最合适。方便转为任意可读格式。而且方便排序、加减、筛选等操作。
nine
2019-04-02 04:44:37 +08:00
从开发的角度来讲不应该使用 timestamp,浪费开发成本。
当然如果你有积累的时间戳处理 lib 并且能熟练处理除外。
如果你有遗留系统使用 timestamp,除外,因为那也是没办法的事。

新系统应尽量使用数据库时间字段
passerbytiny
2019-04-02 08:50:28 +08:00
@richard1122 #33 你是从哪里看出来 DATETIME 是时间戳存储的,自己阅读能力有限,请不要误导人。

DATE DATETIME 是年月日时分秒+纳秒值格式,TIMESTAMP 是时间戳的格式。你就算没看懂 “ MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format.” 这句话,看到'1000-01-01 00:00:00' to '9999-12-31 23:59:59'这种范围,也不应该认为它是时间戳。

The DATE type is used for values with a date part but no time part. MySQL retrieves and displays DATE values in 'YYYY-MM-DD' format. The supported range is '1000-01-01' to '9999-12-31'.

The DATETIME type is used for values that contain both date and time parts. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.

MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)
Jonz
2019-04-02 08:59:05 +08:00
我理解的就是方便处理时区问题
shakoon
2019-04-02 09:36:16 +08:00
当系统并发很高的时候,用秒是远远不够的。一秒钟的数据条数就有成百上千时,用毫秒来记录更准确的发生时间就有意义了。对于金融机构来说,交易流水记到毫秒已经是最宽松的要求了。
jlkm2010
2019-04-02 10:17:38 +08:00
在 mysql 中用 bigint 存储毫秒时间戳
richard1122
2019-04-02 10:31:09 +08:00
@passerbytiny #46 不好意思日常不太用 DATETIME 类型,想当然了。

纠正一下前面的回复,DATETIME 的保存方式参考: https://dev.mysql.com/doc/internals/en/date-and-time-data-type-representation.html
EasyProgramming
2019-04-02 11:43:07 +08:00
tonyaiken
2019-04-02 11:48:58 +08:00
我之前分享过一篇深度探讨计算机应该如何处理时间的文章 https://tonyxu.io/zh/reads/2019-03-03/
aleung
2019-04-02 12:27:42 +08:00
我们的 design guideline:系统内部所有涉及到时间的变量和持久化都统一使用 Unix epoch millisecond,在系统边界(如输入和显示)才转换。这样应用内部的处理才简洁一致。
类似语言编码,在系统内部统一一种编码格式才简单。
yaxin
2019-04-02 15:11:44 +08:00
unixtimestamp 与时区无关
t2doo
2019-04-02 15:20:43 +08:00
汗。。。我一直都是存成 1456794054 这样的,然后 2 个时间相减再求一下时间差。。。还是存成 timestamp 吧
t2doo
2019-04-02 15:21:34 +08:00
错了,还是存成 datetime 吧
gaius
2019-04-02 15:27:53 +08:00
oracle 和 mysql 的 timestamp 类型都没有时区信息。
c4f36e5766583218
2019-04-02 18:06:33 +08:00
以 mysql 来说,用 bigint 来存较好,优点 1. 存储值与时区无关 2. 不用考虑各台机器时区以及 mysql 所用时区不一致问题,缺点: 查询结果需做转换才能可读(mysql-cli/gui)
----
DATETIME: 存储的可以理解为就是你给它的值(yyyy-MM-dd HH:mm:ss),但是不会带上时区信息,所以如果各台机器时区不一致,那库里存的就不知道它的时区了
TIMESTAMP: 存储的可以理解为把你给它的值(yyyy-MM-dd HH:mm:ss)以 mysql 所用时区来理解,转成 UTC 时间来存储,所以如果程序所用时区与 mysql 所用时区不一致,那 mysql 就存错值了
----
那如果程序所用时区与 mysql 所用时区都全部一致,DATETIME 和 TIMESTAMP 有什么区别呢?
1. 各台机器 0 时区,mysqlA 0 时区,数据都在 mysqlA 上,mysqlB 用的是 1 时区,把 mysqlA 导出导入到 mysqlB 中
__DATETIME: A,B 查询结果一致,时区信息自己记得是 0 时区
__TIMESTAMP: A,B 查询结果不同,分别是各自 mysql 所用时区
( ps: 把 mysqlB 时区改一致不就完了......额,就以它不能改吧
2. 其它区别: 如取值范围。。(自己上网看
----
至于闰秒问题。不考虑 2333. [有看到建议取消闰秒]( https://zh.wikipedia.org/wiki/闰秒#建議取消閏秒)
TIMESTAMP 范围问题,程序能活到那个时候再说~(等 mysql 加大 TIMESTAMP 字节?
----
我有试过用 TIMESTAMP(3)的; java 程序里加 Filter 在取值设值时用程序所用时区和 mysql 所用时区差来调整时间 java.util.Date; json api 返回的话是用 Long 的。这样 sql 查库是可读的时间展示,但是其它语言程序好写这样的 Filter 吗?
c4f36e5766583218
2019-04-02 18:12:32 +08:00
#58 ```各台机器```改为```各个程序```比较好,反正大家理解意思就行
ggicci
2019-04-02 20:54:03 +08:00
可以降低理解成本、运维成本,多出来的时间可以泡杯 java 晒晒太阳

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/550865

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX