MySQL日期函数应用 13位时间戳转换为可读日期的技巧

要将13位毫秒级时间戳转换为可读日期,必须先将其除以1000转换为秒级时间戳,再使用from_unixtime函数处理,例如select from_unixtime(your_timestamp_ms / 1000)可得到标准日期格式,结合date_format可自定义输出样式,如仅显示日期或中文格式,而处理时区问题则需使用convert_tz函数明确指定源时区和目标时区,确保时间显示准确无误。

MySQL日期函数应用 13位时间戳转换为可读日期的技巧

很多时候,我们从前端或者其他系统拿到一个时间戳,发现它不是常见的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'

在我看来,处理时间戳和日期时,最稳妥的做法是:

  1. 明确来源时区:搞清楚你的13位时间戳是在哪个时区下生成的。
  2. 统一存储:如果可能,所有时间戳都统一转换为UTC存储(或者至少在数据库中以UTC时间来理解
    FROM_UNIXTIME

    的结果)。

  3. 显示转换:在查询显示时,再根据用户或应用的需求,将其转换为目标时区。

这样,无论你的应用部署在哪里,或者用户来自何方,时间显示都能保持一致性和准确性,避免很多不必要的困扰。这是一个经验之谈,因为时区问题一旦处理不好,调试起来真的会让人头疼。

© 版权声明
THE END
喜欢就支持一下吧
点赞5 分享