+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
|                                       TIMESTAMP                                       |                                 DATETIME                                 |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
| TIMESTAMP requires 4 bytes.                                                           | DATETIME requires 8 bytes.                                               |
| Timestamp is the number of seconds that have elapsed since January 1, 1970 00:00 UTC. | DATETIME is a text displays 'YYYY-MM-DD HH:MM:SS' format.                |
| TIMESTAMP supported range: ‘1970-01-01 00:00:01′ UTC to ‘2038-01-19 03:14:07′ UTC.    | DATETIME supported range: ‘1000-01-01 00:00:00′ to ‘9999-12-31 23:59:59′ |
| TIMESTAMP during retrieval converted back to the current time zone.                   | DATETIME can not do this.                                                |
| TIMESTAMP is used mostly for metadata i.e. row created/modified and audit purpose.    | DATETIME is used mostly for user-data.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

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

on update CURRENT_TIMESTAMP

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

我建议不要使用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）中看到的所有这些花哨的数据类型几乎没有增加任何内容，并使您开始进入供应商锁定状态。

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

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

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

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

2016+：我建议您将Mysql时区设置为UTC，并使用DATETIME:

任何最近的前端框架（Angular 1/2、react、Vue…）都可以轻松自动地将UTC日期时间转换为本地时间。

此外：

DATETIME现在可以自动设置为当前时间值。如何设置MySQL DATETIME列的默认值？与人们可能认为的相反，DATETIME比TIMESTAMP快，http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-myisam/TIMESTAMP仍然限于1970-2038

（除非您可能更改服务器的时区）

AngularJs示例

// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...

// font-end Output the localised time
{{item.my_datetime | date :'medium' }}

此处提供所有本地化时间格式：https://docs.angularjs.org/api/ng/filter/date