我建议不要使用DATETIME或TIMESTAMP字段。如果你想将一个特定的日子作为一个整体来表示（比如生日），那么就使用DATE类型，但是如果你要更具体一些，你可能会对记录一个实际的时刻感兴趣，而不是一个时间单位（日、周、月、年）。不要使用DATETIME或TIMESTAMP，而是使用BIGINT，只需存储自epoch以来的毫秒数（如果使用Java，则为System.currentTimeMillis（））。这有几个优点：

避免供应商锁定。几乎每个数据库都以相对类似的方式支持整数。假设您想移动到另一个数据库。您想担心MySQL的DATETIME值之间的差异以及Oracle如何定义它们吗？即使在不同版本的MySQL中，TIMESTAMPS也具有不同的精度级别。直到最近，MySQL才支持时间戳中的毫秒。没有时区问题。这里有一些关于不同数据类型的时区的见解。但这是常识吗？你的同事会花时间学习吗？另一方面，很难将BigINT更改为java.util.Date。使用BigINT会导致很多时区问题被搁置一旁。无需担心范围或精度。你不必担心未来日期范围会缩短什么（TIMESTAMP只适用于2038年）。第三方工具集成。通过使用整数，第三方工具（例如EclipseLink）与数据库的接口很简单。并非所有第三方工具都会像MySQL一样理解“datetime”。如果您使用这些自定义数据类型，想尝试在Hibernate中确定是否应该使用java.sql.TimeStamp或java.util.Date对象？使用基本数据类型使第三方工具的使用变得微不足道。

这个问题与如何在数据库中存储货币值（即1.99美元）密切相关。你应该使用十进制，还是数据库的货币类型，或者最糟糕的是双精度？由于上面列出的许多相同原因，所有三种选择都很糟糕。解决方案是使用BIGINT将货币的价值存储为美分，然后在向用户显示价值时将美分转换为美元。数据库的工作是存储数据，而不是插入数据。您在数据库（尤其是Oracle）中看到的所有这些花哨的数据类型几乎没有增加任何内容，并使您开始进入供应商锁定状态。

到目前为止，还没有提到DEFAULT CURRENT_TIMESTAMP只适用于时间戳，而不适用于DateTime类型字段。

这与只能使用DateTime而不能使用Timestamp的MS Access表相关。

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

on update CURRENT_TIMESTAMP

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

在我的例子中，我将UTC设置为所有事物的时区：系统、数据库服务器等，只要我能做到这一点。如果我的客户需要另一个时区，那么我会在应用程序上配置它。

我几乎总是喜欢时间戳而不是日期时间字段，因为时间戳隐含地包含时区。因此，由于从不同时区的用户访问应用程序的那一刻起，您希望他们在本地时区中查看日期和时间，因此与数据保存在datetime字段中相比，此字段类型更容易实现。

另外，在将数据库迁移到另一个时区的系统的情况下，我会更加自信地使用时间戳。更不用说在计算两个时刻之间的差异时可能出现的问题，这两个时刻间的总时间变化较大，并且需要1小时或更短的精度。

总之，我看重时间戳的优点：

可在国际（多时区）应用程序上使用在时区之间轻松迁移很容易计算差异（只需减去两个时间戳）不用担心夏天的约会

出于所有这些原因，我选择了UTC和时间戳字段。我避免头痛；）

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

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

在MySQL 5及以上版本中，TIMESTAMP值从当前时区转换为UTC进行存储，并从UTC转换回当前时区进行检索。（这仅适用于TIMESTAMP数据类型，而不适用于DATETIME等其他类型。）

默认情况下，每个连接的当前时区是服务器的时间。可以根据每个连接设置时区，如MySQL Server时区支持中所述。