unix时间戳是存储时间戳的最佳方式吗?

Ric*_*haw 54 timestamp

我总是使用unix时间戳来处理所有事情,但我想知道是否有更好的方法.

你用什么来存储时间戳?为什么?

J c*_*J c 91

但是,如果选择存储时间戳,则避免区域解释问题和时间偏移问题非常重要.无论区域如何,Unix时间戳都被解释为相同,并且无论时区如何都是从同一时间点计算的 - 这些都是好事.

请注意将时间戳存储为模糊字符串,例如01/02/2008,因为这可以解释为2008年1月2日或2008年2月1日,具体取决于区域设置.

存储小时/分钟/秒时,重要的是要知道"指定了"哪个小时/分钟/秒.您可以通过包含时区信息(Unix时间戳不需要,因为它假定为UTC)来完成此操作.

但请注意,Unix时间戳不能唯一地表示某些时刻:当UTC中存在闰秒时,Unix时间戳不会改变,因此UTC时间23:59:60和第二天00:00:00都有相同的时间戳Unix表示法.因此,如果您确实需要一秒或更好的分辨率,请考虑另一种格式.

如果您更喜欢比Unix时间戳更易于阅读的人类可读格式,请考虑使用ISO 8601.

一种有助于保持直观的技术是将日期存储为UTC,并且仅在向用户显示日期时应用时区或DST偏移.

  • 准确地说,您不能忽略时区。单个时间戳意味着仅基于时区的不同时刻。这也不能假设仅使用偏移量即可解决,因为偏移量会发生变化,例如夏令时。https://derickrethans.nl/storing-date-time-in-database.html (3认同)

Rya*_*yan 26

如果你要存储一个日志文件,请为皮特的爱而使它成为人类可读和词法排序的东西.

2008-10-07 09:47:02例如

  • 7年......人类可读性很好而且我都是为了它,但这个例子中的日期是模棱两可的.如果你真的需要知道什么时候发生了什么,你需要时区信息,所以请选择像2008-10-07T09:47:02Z这样的东西,这样你就可以获得人类的可读性和准确的时间点. (3认同)
  • 这不是模棱两可的.没有`???? - ?? - ??`日期格式不是'yyyy-mm-dd`,即ISO-8601除了"T". (3认同)
  • 我喜欢你花点时间点击帖子按钮 (2认同)
  • @ChristofferHammarström 我认为他们指的是日期时间(不仅仅是日期)。所以是的,它是不明确的,因为 Ryan 的示例中没有时区信息。 (2认同)

Tho*_*ens 14

32位Unix时间戳将在几年内(2038年1月)溢出,因此可能需要考虑.我通常在SQL中使用DATETIME格式,即YYYY-MM-DD HH:MM:SS,时间为24小时制.我尝试以相同的格式输出文件,只是为了让我的生活更轻松.

  • @Andre:64位操作系统与它几乎无关:它取决于你如何存储时间戳.如果您使用的是32位int(例如,在C中,大多数64位系统上的`int`类型),那么您仍然会遇到问题.同样,大多数32位系统都可以轻松使用64位int,并且可以通过这种方式免疫.你必须看看你如何将数据存储在你存储的任何存储介质中,无论是RAM,磁盘,网络传输等...... (14认同)
  • 是的.对于在2038年运行32位操作系统的人来说,这只会是一个问题.恕我直言 - 这是值得的.即使现在大多数系统都使用64位操作系统.64位操作系统的到期日为12月4日星期日292,277,026,596. (3认同)

Mar*_*ett 6

你需要什么时代存储和解决方案?如果你需要微秒,或石器时代的日期time_t可能不是最好的.出于一般商业目的,这是相当不错的(假设64位)


pmg*_*pmg 5

这取决于您需要时间戳的用途。

unix 时间戳不能表示 2008-12-31T23:59:59Z 之后 1 秒的时间。如果您使用 unix 时间戳执行 '2009-01-01T09:00:00' - '2008-12-31T09:00:00' ,结果不正确:这两个日期之间会有闰秒,并且它们是分开的86401 秒(不是 Unix 时间戳告诉你的 86400)。

除此之外以及其他响应者所说的,是的——unix 时间戳是正确的方法:)