以下示例显示了在将时区更改为“america/new_york”（DATETIME不变）后，TIMESTAMP日期类型如何更改值。

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

我已经把我的答案转换成了文章，这样更多的人可以发现这个有用的MySQL：日期时间与时间戳数据类型。

我发现TIMESTAMP能够基于当前时间自动更新自己，而不使用不必要的触发器，这一点非常有用。虽然TIMESTAMP是UTC，但这只是我自己。

它可以跟踪不同的时区，因此如果您需要显示相对时间，例如UTC时间就是您想要的。

TIMESTAMP需要4个字节，而DATETIME需要8个字节。

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

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

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

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

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

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

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

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

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

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

当您有来自不同国家、不同时区的游客时，TIMESTAMP非常有用。您可以轻松地将TIMESTAMP转换为任何国家/地区的时区