对于您在问题上使用的特定示例（1200年），从技术上讲，一切正常。

但是，通常不建议为此目的使用时间戳。首先，范围限制是任意的：在MySQL中，它是1000年1月1日。如果您使用的是12-13世纪的东西，一切都会好起来的……但是，如果您需要添加一些更旧的东西（10世纪或更早的东西），
，日期将非常糟糕，并且解决该问题将需要将所有历史日期重新设置为更适当的格式。

时间戳通常表示为原始整数，具有给定的“滴答间隔”和“纪元点”，因此，实际上，该数字是从纪元到代表日期为止所经过的滴答数（反之亦然）。这意味着，与任何带有固定整数的数据类型一样，可表示值的集合是有限的。我知道大多数时间戳格式都以牺牲精度为代价，这主要是因为需要执行时间算术的应用程序通常需要以相当高的精度进行；而需要使用历史日期的应用程序很少需要执行严格的算术运算。

换句话说，时间戳用于 精确 表示日期。第二（甚至一秒）的精确度对于历史日期是没有意义的：您能告诉我，以毫秒为单位，亨利八世被加冕为英格兰国王吗？

在MySQL的情况下，格式固有地定义为“ 4位数字的年份”，因此任何相关的优化都可以基于以下假设：年份将为4位数字，或者整个字符串将完全为10个字符（“
yyyy- mm-
dd“）等。幸运的是，您在标题上提到的日期仍然合适，但是即使依靠该日期也仍然很危险：除了数据库本身可以存储的内容之外，您还需要知道服务器堆栈的其余部分可以操纵。例如，如果您使用PHP与数据库进行交互，则尝试处理历史日期很可能会在某些时候崩溃（在32位环境中，UNIX风格的时间戳的范围是1901年12月13日至2038年1月19日）。

总结：MySQL可以正确存储4位数字的任何日期。但总的来说，使用时间戳作为历史日期几乎可以肯定会引发问题和头痛。我强烈建议您不要使用这种用法。

希望这可以帮助。

编辑/添加：

谢谢您的回答。我应该为历史日期创建自己的算法还是选择另一个数据库，但选择哪个数据库？–用户284523

我认为没有任何数据库对这种日期有太多的支持：使用它的应用程序最经常具有足够的字符串/文本表示形式。实际上，对于第1年及以后的日期，文本表示甚至会产生正确的排序/比较（只要该日期由数量级表示：y，m，d顺序）。但是，如果还涉及“负数”日期，则比较会中断（它们的比较仍会早于任何正数日期，但是比较两个负数日期将得出相反的结果）。

如果只需要1年级和以后的日期，或者不需要排序，那么使用字符串可以使您的生活变得更加轻松。

否则，最好的方法是使用某种数字，并定义自己的“刻度间隔”和“时期点”。一个好的间隔可能是几天（除非您确实需要进一步的说明，但是即使那样，您也可以依靠“实数”（浮点数）而不是整数）；合理的时期可能是1月1日。主要问题是将这些值转换为文本表示形式，反之亦然。您需要牢记以下细节：

• years年多了一天。
• leap年的规则是“ 4的倍数”，直到1582年才从儒略历改为公历，并变成“ 4的倍数，除非是100的倍数，除非它们也是400的倍数”。
• 朱利安历的最后一天是1582年10月4日。第二天，是阳历的第一天，是1582年10月15日。为了使新的历法与季节重新匹配，跳过了10天。
• 如评论中所述，以上两个规则因国家/地区而异：教皇制国家和一些天主教国家的确在指定日期采用了新日历，但许多其他国家/地区采取了更长的时间（最后一个是1926年的土耳其）。这意味着从1582年的教皇公牛到1926年的最后一次收养之间的任何日期，如果没有地理环境，都将是模棱两可的，而且处理起来会更加复杂。
• 没有“ 0年”：1年之前的一年是-1年，或BCE 1年。

所有这些都需要相当复杂的解析器和格式化程序功能，但是除了很多情况之外，并没有太多的复杂性（编写代码很繁琐，但是很简单）。使用数字作为基础表示形式可确保对任何一对值进行正确的排序/比较。

了解了这一点，现在您可以选择采用更适合您需求的方法。