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

我一直使用unix时间戳,但是想知道是否有更好的方法。

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

但是,您select存储时间戳,避免区域解释问题和时间偏移问题很重要。 一个Unix时间戳不pipe区域如何都是相同的,并且是从相同的时间点计算出来的,不pipe时区如何 – 这些都是好事。

请注意将时间戳存储为不明确的string,例如01/02/2008,因为这可以解释为2008年1月2日或2008年2月1日,具体取决于语言环境。

当存储小时/分钟/秒时,知道“哪个”小时/分钟/秒被指定是很重要的。 您可以通过包含时区信息(Unix时间戳不需要,因为它被认为是UTC)来做到这一点。

但是请注意,Unix时间戳不能唯一地表示一些时间点:当UTC出现闰秒时,Unix时间戳不会改变,因此第二天23:59:60 UTC和00:00:00都是相同的Unix表示。 所以如果你真的需要一秒或更好的分辨率,考虑另一种格式。

如果您比Unix时间戳更喜欢更易于读取的存储格式,请考虑使用ISO 8601 。

一种有助于保持简单性的技术是将date存储为UTC,并在向用户显示date时仅应用时区或DST偏移量。

如果你正在存储一个日志文件,请为pete的爱做一些人类可读和词汇sorting的东西。

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

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

你需要存储什么样的时代以及什么样的解决scheme? 如果你需要微秒,或石器时代的datetime_t可能不是最好的。 对于一般的商业目的,这是相当不错的(假设64位)

这取决于你需要什么时间戳。

unix时间戳不能代表2008-12-31T23:59:59Z之后1秒的时间。 如果你使用unix时间戳做'2009-01-01T09:00:00' – '2008-12-31T09:00:00',结果是不正确的:在这两个date之间会有一个闰秒,它们是分开的到86401秒(不是86400,因为unix时间戳会告诉你)。

除此之外,其他响应者说,是的 – unix时间戳是要走的路:)

对于数据库,时间戳不是一个好主意,因为它们不考虑夏令时或当前的本地时间。 在MySQL上最好把它存储一次,然后使用MySQLdate和时间函数来检索你想要的部分,或者与其他date进行比较。

timeval风格(time_t +微秒),如果我需要亚秒精度,否则只是time_t。 您可以使用64位整数值来存储time_t * 1000000 + usec,并且您可以在+/- 292,000年以上进行溢出保护。

UNIX时间戳32位问题似乎是非常烦人的用户谁进入2038年以后的date。

为MySQL使用DATETIME序列,或者将date保存为BIGINT(8)unsigned(max:18 quintillion)或FLOAT,以便input大数字。 那么你不能使用PHP的date()函数,因为它只允许整数作为参数(受32位系统限制)。

我find的解决scheme是使用PHP 5.2.0函数。 这是DateTime PHP解决scheme 。

无需更改UNIX_TIMESTAMP格式。 只要你有BIGINT(8)作为你的MySQL存储时间戳。 你将不再受到32位系统的限制。

时间戳基本上是:

  • 一个明显的时间点

作为一个时间点,有一个无止境的决议,select一个时间戳格式的重要事情是:有足够的决议?

  • Unix时间仅在几秒钟内计数。
  • 分机4有纳秒
  • Java有纳秒

对于我所使用的大多数应用来说,纳秒就足够了。 所以到目前为止,Java时间戳对我来说是正确的。