要将13位毫秒级时间戳转换为可读日期，必须先将其除以1000转换为秒级时间戳，再使用from_unixtime函数处理，例如select from_unixtime(your_timestamp_ms / 1000)可得到标准日期格式，结合date_format可自定义输出样式，如仅显示日期或中文格式，而处理时区问题则需使用convert_tz函数明确指定源时区和目标时区，确保时间显示准确无误。
很多时候，我们从前端或者其他系统拿到一个时间戳，发现它不是常见的10位，而是13位。这通常意味着它是一个毫秒级的时间戳。在MySQL里，如果我们想把它变成我们能看懂的日期格式，核心思路就是把它除以1000，变成秒级时间戳，再用
FROM_UNIXTIME函数处理。
解决方案
要将MySQL中存储的13位毫秒级时间戳转换为可读日期，你可以直接使用
FROM_UNIXTIME函数，但别忘了先将时间戳除以1000。
例如，如果你的13位时间戳存储在名为
your_timestamp_ms的列中：
SELECT
FROM_UNIXTIME(your_timestamp_ms / 1000) AS readable_datetime,
DATE_FORMAT(FROM_UNIXTIME(your_timestamp_ms / 1000), '%Y-%m-%d %H:%i:%s') AS formatted_datetime,
DATE_FORMAT(FROM_UNIXTIME(your_timestamp_ms / 1000), '%Y年%m月%d日') AS chinese_date
FROM
your_table_name;这里，
FROM_UNIXTIME(your_timestamp_ms / 1000)会将毫秒级时间戳转换为标准的 'YYYY-MM-DD HH:MM:SS' 格式。如果你需要更具体的格式，比如只显示日期，或者带有时区信息，那就需要结合
DATE_FORMAT或
CONVERT_TZ。
为什么会出现13位时间戳？它与10位时间戳有何区别？
说起来，13位时间戳的出现，主要是为了追求更高的精度。我们平时最常接触的10位时间戳，通常是Unix时间戳，它记录的是从1970年1月1日00:00:00 UTC到现在的秒数。但在很多现代应用场景，尤其是涉及到实时数据、毫秒级事件记录或者高并发系统时，秒的精度就不够用了。比如JavaScript的
Date.now()、Java的
System.currentTimeMillis()等，它们默认返回的就是毫秒级时间戳，也就是13位数字。
在我看来，这种设计虽然提供了更高精度，但同时也带来了一些小麻烦。最常见的坑就是，很多人不假思索地把13位时间戳直接扔给
FROM_UNIXTIME，结果得到一个完全不对劲的日期，甚至可能是一个未来的日期，因为函数会把这些毫秒当成秒来解析，那数字自然就大得离谱了。所以，理解它们之间的单位差异——一个是秒，一个是毫秒——是处理这类问题的起点。简单来说，13位时间戳就是10位时间戳乘以1000。
如何将13位时间戳转换为不同的日期显示格式？
当我们将13位时间戳成功转换为MySQL可识别的日期时间类型后，下一步通常是根据业务需求将其显示为不同的格式。这时，
DATE_FORMAT()函数就派上大用场了。它允许你通过格式化字符串来精确控制输出的日期时间样式。
举个例子，假设我们已经通过
FROM_UNIXTIME(your_timestamp_ms / 1000)得到了一个日期时间值。
如果你只想显示日期部分，比如“2023-10-26”：
SELECT DATE_FORMAT(FROM_UNIXTIME(your_timestamp_ms / 1000), '%Y-%m-%d') AS only_date FROM your_table_name;
如果你想显示具体的时分秒，比如“14:35:01”：
SELECT DATE_FORMAT(FROM_UNIXTIME(your_timestamp_ms / 1000), '%H:%i:%s') AS only_time FROM your_table_name;
或者，你想显示一个更具中文习惯的格式，比如“2023年10月26日 星期四 14点35分01秒”：
SELECT DATE_FORMAT(FROM_UNIXTIME(your_timestamp_ms / 1000), '%Y年%m月%d日 %W %H点%i分%s秒') AS custom_chinese_format FROM your_table_name;
这里
%Y代表四位年份，
%m代表两位月份，
%d代表两位日期，
%H代表24小时制小时，
%i代表分钟，
%s代表秒，而
%W则代表星期几的完整名称。
DATE_FORMAT()的强大之处在于它提供了非常丰富的格式化符号，几乎可以满足所有你能想到的日期时间显示需求。我觉得，掌握这些格式化符号，能让你的数据展示更加灵活和人性化。
处理13位时间戳时，如何应对时区问题？
时区问题，嗯，这是个老生常谈但又特别容易踩坑的地方。特别是当你处理来自不同系统或不同地理位置的时间数据时，时区就成了绕不开的话题。MySQL的
FROM_UNIXTIME()函数，它会将Unix时间戳（这个时间戳本身是UTC时间）转换成MySQL服务器当前时区下的日期时间。这意味着，如果你的MySQL服务器时区设置是北京时间（东八区），那么
FROM_UNIXTIME()出来的就是北京时间。
但问题来了，如果你的13位时间戳，比如是从一个海外服务器生成，或者你的应用逻辑期望的是UTC时间，而MySQL服务器又是本地时区，那结果就可能出现偏差。
要明确地处理时区，你可以使用
CONVERT_TZ()函数。它的基本用法是
CONVERT_TZ(dt, from_tz, to_tz)。
dt是你想要转换的日期时间值，
from_tz是原始时区，
to_tz是目标时区。
举个例子：
假设你的13位时间戳
your_timestamp_ms实际上代表的是UTC时间，但你想在MySQL中以北京时间（+08:00）显示它：
SELECT
CONVERT_TZ(FROM_UNIXTIME(your_timestamp_ms / 1000), 'UTC', '+08:00') AS beijing_time,
CONVERT_TZ(FROM_UNIXTIME(your_timestamp_ms / 1000), 'UTC', 'America/New_York') AS new_york_time
FROM
your_table_name;这里的
'UTC'和
'+08:00'是时区字符串或偏移量。为了让
CONVERT_TZ()能够识别命名时区（如'America/New_York'），你的MySQL服务器需要加载时区信息。如果没有加载，你可能就只能用偏移量，比如
'+08:00'。
在我看来，处理时间戳和日期时，最稳妥的做法是：
- 明确来源时区：搞清楚你的13位时间戳是在哪个时区下生成的。
-
统一存储：如果可能，所有时间戳都统一转换为UTC存储（或者至少在数据库中以UTC时间来理解
FROM_UNIXTIME
的结果）。 - 显示转换：在查询显示时，再根据用户或应用的需求，将其转换为目标时区。
这样，无论你的应用部署在哪里，或者用户来自何方，时间显示都能保持一致性和准确性，避免很多不必要的困扰。这是一个经验之谈，因为时区问题一旦处理不好，调试起来真的会让人头疼。
