MySQL没有提供默认值时，时间戳的默认值无效。

请看下面的sql语句

CREATE SCHEMA IF NOT EXISTS `scheduler`;
USE `scheduler` ;
CREATE TABLE IF NOT EXISTS `scheduler`.`JobHistory` (
  `Id` INT NOT NULL AUTO_INCREMENT,
  `Job` INT NOT NULL,
  `StartTime` TIMESTAMP NOT NULL,
  `FinishTime` TIMESTAMP NOT NULL,
  PRIMARY KEY (`Id`),
  INDEX `fk_JobHistory_Job_idx` (`Job` ASC));

它正在抛出

ErrorCode:1067。“完成时间”的默认值无效。

---

但是我没有给完成时间提供任何默认值，还有另一个时间戳

StartTime

，它完全相同，我没有得到任何例外

您应该为StartTime和FinishTime列使用DATETIME数据类型。时间戳有一个非常特殊的用法。请参阅

>P>尽管@ JSnPrANK是正确的，但是时间戳被不同对待，您应该考虑使用这2个特定列的DATETIME数据类型，但是，他无法解释错误消息。 错误消息很可能是mysql在未提供默认值时如何处理时间戳字段以及sql模式设置的组合结果

您可以将两个时间戳列定义为NOTNULL，而不设置任何特定的默认值。这意味着第一个timestamp列的默认值将是current_timestamp（），并且在记录更改时也将更新为current_timestamp（）。这就是为什么第一个时间戳字段不会生成错误消息的原因，无论2中的哪一个是第一个

但是，如果未明确定义默认值，则第二个not null timestamp列的默认值将为“0000-00-00 00:00:00”

看

您的服务器上也可能显式启用sql模式，或者作为严格sql模式的一部分启用sql模式。如果要将“0000-00-00 00:00:00”设置为默认值或要将此值插入任何日期字段，此sql模式将生成错误

因此，您可以在表中使用timestamp数据类型，但将第二个数据类型设置为null，或者提供0或任何有效日期（如历元）作为显式默认值

---

由于您使用这些字段标记开始日期和结束日期，因此使用datetime而不是timestamp作为数据类型可能是一个好主意。

引用2000年的文章并没有真正的帮助，因为从那时起已经发生了很多变化，可能不再是真的。正如其他相关问题中已经提到的，时间戳值参考了UTC 1970年1月1日的特定时间点。DATETIME值恰恰相反，它只存储一些日期和时间，而不引用任何时间点。它们更像是显示值，墙上的时钟向你显示一些值。如果您想跟踪事件发生的时间，日期时间为2018-01-12 14:00:00的日期时间在不同的时区可能是不同的时间

另一方面，时间戳始终存储为UTC，在datetime函数中读取或使用时，会自动转换回连接或数据库的默认时区。因此，当您的连接设置为+02:00时，时间戳列中存储的实际值将是

2018-01-12 12:00:00

，而不是

2018-01-12 14:00:00

。然后，当您阅读带有+05:00连接的专栏时，您将看到

2018-01-12 17:00:00

。无论为数据库或连接设置了什么时区，DATETIME值始终保持在

2018-01-12 14:00:00

---

因此，对于跟踪何时发生或何时将/应该发生的事情，时间戳是一种方法。当您只想存储一个独立于时区的固定日期时间时，请使用DATETIME（例如，用户应在凌晨2点收到一封电子邮件，因为凌晨2点对每个人都是一样的）。

有趣的是，如果我删除StartTime列或FinishTime列，它将正常工作。看起来MySQL不允许没有默认值的第二个时间戳。