这里的许多答案都建议将时间戳存储为时间戳，以防必须表示定义良好的时间点。但是，如果您按照惯例将所有时间点都存储在UTC中，那么您也可以使用datetime获取时间点。

这取决于应用程序。

考虑由用户在纽约的服务器上设置时间戳，以便在桑海进行约会。现在，当用户在桑海连接时，他从东京的镜像服务器访问相同的预约时间戳。他将在东京时间看到这一任命，而不是原定的纽约时间。

因此，对于表示用户时间（如约会或日程）的值，datetime更好。它允许用户控制所需的确切日期和时间，而不考虑服务器设置。设置时间是设置时间，不受服务器时区、用户时区或夏时制计算方式变化的影响（是的，它会变化）。

另一方面，对于表示系统时间的值，如支付事务、表修改或日志记录，始终使用时间戳。将服务器移动到另一个时区或在不同时区的服务器之间进行比较时，系统不会受到影响。

时间戳在数据库上也更轻，索引速度更快。

在使用MySQL和PHP时，我总是使用Unix时间戳。这主要是因为PHP中的默认日期方法使用时间戳作为参数，因此不需要解析。

要获取PHP中当前的Unix时间戳，只需执行time（）；在MySQL中执行SELECT UNIX_TIMESTAMP（）；。

值得注意的是，在MySQL中，您可以在创建表列时使用以下内容：

on update CURRENT_TIMESTAMP

这将更新每次修改行时的时间，有时对存储的上次编辑信息非常有用。这只适用于时间戳，但不适用于日期时间。

主要区别在于DATETIME是常量，而TIMESTAMP受时区设置的影响。

因此，只有当您已经或者将来可能已经跨时区同步集群时，这才是重要的。

简单地说：如果我在澳大利亚有一个数据库，并转储该数据库以同步/填充美国的数据库，则TIMESTAMP将更新以反映新时区中事件的实时，而DATETIME仍将反映非时区中事件发生的时间。

DATETIME的一个很好的例子是在Facebook中使用TIMESTAMP，在那里他们的服务器从来都不太确定跨时区发生的时间。有一次，我正在进行一次谈话，在谈话中，时间说我在消息实际发送之前回复消息。（当然，如果时间是发布的而不是同步的，这也可能是由于消息传递软件中的时区转换错误造成的。）

TIMESTAMP始终采用UTC格式（即自1970-01-01以来的秒数，采用UTC格式），MySQL服务器会自动将其转换为连接时区的日期/时间。从长远来看，TIMESTAMP是一条可行的道路，因为您知道您的时间数据将始终采用UTC格式。例如，如果您迁移到其他服务器或更改服务器上的时区设置，您就不会把日期搞砸。

注意：默认连接时区是服务器时区，但这可以（应该）在每个会话中更改（请参见SET time_zone=…）。