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时间戳对我来说是正确的。
