- 长度问题。
在一些博文中看到有这样的描述:
TIMESTAMP 列类型
TIMESTAMP 值可以从 1970 的某时的开始一直到 2037 年,精度为一秒,其值作为
数字显示。
TIMESTAMP 值显示尺寸的格式如下表所示:
:
+---------------+----------------+
| 列类型 | 显示格式 |
| TIMESTAMP(14) | YYYYMMDDHHMMSS |
| TIMESTAMP(12) | YYMMDDHHMMSS |
| TIMESTAMP(10) | YYMMDDHHMM |
| TIMESTAMP(8) | YYYYMMDD |
| TIMESTAMP(6) | YYMMDD |
| TIMESTAMP(4) | YYMM |
| TIMESTAMP(2) | YY |
+---------------+----------------+
“完整”TIMESTAMP 格式是 14 位,但 TIMESTAMP 列也可以用更短的显示尺寸创造
最常见的显示尺寸是 6、8、12、和 14。
你可以在创建表时指定一个任意的显示尺寸,但是定义列长为 0 或比 14 大均会
被强制定义为列长 14。
列长在从 1~13 范围的奇数值尺寸均被强制为下一个更大的偶数。
列如:
定义字段长度 强制字段长度
TIMESTAMP(0) -> TIMESTAMP(14)
TIMESTAMP(15)-> TIMESTAMP(14)
TIMESTAMP(1) -> TIMESTAMP(2)
TIMESTAMP(5) -> TIMESTAMP(6)所有的 TIMESTAMP 列都有同样的存储大小,
使用被指定的时期时间值的完整精度(14 位)存储合法的值不考虑显示尺寸。
不合法的日期,将会被强制为 0 存储*这有几个含意: *
1、虽然你建表时定义了列 TIMESTAMP(8),但在你进行数据插入与更新时
TIMESTAMP 列实际上保存了 14 位的数据(包括年月日时分秒),只不过在你进行查
询时 MySQL 返回给你的是 8 位的年月日数据。如果你使用 ALTER TABLE 拓宽一个狭窄
的 TIMESTAMP 列,以前被“隐蔽”的信息将被显示。
2、同样,缩小一个 TIMESTAMP 列不会导致信息失去,除了感觉上值在显示时,
较少的信息被显示出。
3、尽管 TIMESTAMP 值被存储为完整精度,直接操作存储值的唯一函数是
UNIX_TIMESTAMP();由于 MySQL 返回 TIMESTAMP 列的列值是进过格式化后的检索的
值,这意味着你可能不能使用某些函数来操作 TIMESTAMP 列(例如 HOUR()或 SECOND
()),除非 TIMESTAMP 值的相关部分被包含在格式化的值中。例如,一个 TIMESTAMP
列只有被定义为 TIMESTAMP(10)以上时,TIMESTAMP 列的 HH 部分才会被显示,因此在
更短的 TIMESTAMP 值上使用 HOUR()会产生一个不可预知的结果。
4、不合法 TIMESTAMP 值被变换到适当类型的“零”值(00000000000000)。
(DATETIME,DATE 亦然)
但是,当使用如下语句时:
ALTER TABLE myemp ADD COLUMN hiredate1 TIMESTAMP(14);
会提示:1426 - Too-big precision 14 specified for 'hiredate1'. Maximum is 6.
因此,MySQL 中的 TIMESTAMP
数据长度到底是多少呢?(本地 MySQL 版本为 8.0)
timestamp
类型的起始时间是1970-01-01 00:00:01 UTC
,和时区是关系的。如果我没有理解错的话,MySQL 将 timestamp 类型的值保存的时候,会从当前时区转成 UTC 时间,正好解释了前面1970-01-01 00:00:00
或1970-01-01 00:00:01
两个值保存时出错的问题了。从当前时区转成 UTC 时间需要减去『8 小时』,结果就不在timestamp
类型的范围内了。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于