数据库中的日期显示格式如何修改成自己想要的？

在处理数据时，我们经常遇到一个看似简单却至关重要的问题：数据库中展示的日期格式不符合我们的阅读习惯或业务需求，数据库默认返回的 2025-10-27 14:30:00 格式，我们可能希望将其显示为更友好的 2025年10月27日 或 27/10/2025，要解决这个问题，首先需要明确一个核心概念：数据库存储日期时间和展示日期时间是两个独立的环节，数据库为了确保数据的准确性和可计算性，通常以标准化的内部格式（如 DATETIME, TIMESTAMP）存储日期，而我们看到的格式，是在查询和展示过程中进行转换的结果，改变日期格式主要有两种途径：在数据库层面通过SQL函数进行转换,或者在应用程序层面进行格式化。

在数据库层面使用SQL函数格式化

这是最直接的方式，通过在SQL查询语句中调用特定数据库的日期格式化函数，可以直接返回格式化后的字符串，这种方式非常适合进行快速的数据报表生成、数据导出或即席查询。

MySQL 数据库

MySQL 提供了非常强大的 DATE_FORMAT() 函数,它允许你使用一系列的格式说明符来自定义日期的显示方式。

基本语法：

SELECT DATE_FORMAT(date_column, format_string) FROM table_name;

示例：
假设有一个 orders 表，其中包含一个 order_date 列（类型为 DATETIME）。

-- 将日期格式化为 "年-月-日" 格式
SELECT DATE_FORMAT(order_date, '%Y-%m-%d') AS formatted_date FROM orders;
-- 将日期格式化为更友好的 "XXXX年XX月XX日" 格式
SELECT DATE_FORMAT(order_date, '%Y年%m月%d日') AS formatted_date FROM orders;
-- 包含时间的格式 "XXXX年XX月XX日 HH:MM:SS"
SELECT DATE_FORMAT(order_date, '%Y年%m月%d日 %H:%i:%s') AS formatted_date FROM orders;

常用格式说明符：

说明符	描述	示例
%Y	四位数的年份	2025
%y	两位数的年份	23
%m	月份 (01-12)	10
%c	月份 (1-12)	10
%d	月中的天数 (00-31)	27
%H	小时 (00-23)	14
%i	分钟 (00-59)	30
%s	秒 (00-59)	00

SQL Server 数据库

SQL Server 提供了 CONVERT() 和 FORMAT() 两个函数。CONVERT() 通过预定义的样式代码进行转换，效率较高但灵活性稍差；FORMAT() 则更灵活，语法类似 .NET 的格式化字符串。

使用 CONVERT() 函数：

-- 样式 105: dd-mm-yyyy
SELECT CONVERT(VARCHAR, order_date, 105) FROM orders;
-- 样式 111: yyyy/mm/dd
SELECT CONVERT(VARCHAR, order_date, 111) FROM orders;
-- 样式 120: yyyy-mm-dd hh:mi:ss
SELECT CONVERT(VARCHAR, order_date, 120) FROM orders;

使用 FORMAT() 函数 (SQL Server 2012+)：

-- 自定义格式
SELECT FORMAT(order_date, 'yyyy-MM-dd') FROM orders;
SELECT FORMAT(order_date, 'yyyy年MM月dd日') FROM orders;

Oracle 数据库

Oracle 使用 TO_CHAR() 函数将日期类型转换为字符类型,并提供了丰富的格式模型。

示例：

-- 标准格式
SELECT TO_CHAR(order_date, 'YYYY-MM-DD') FROM orders;
-- 带有中文的格式
SELECT TO_CHAR(order_date, 'YYYY"年"MM"月"DD"日"') FROM orders;
-- 包含时间的24小时制格式
SELECT TO_CHAR(order_date, 'YYYY-MM-DD HH24:MI:SS') FROM orders;

PostgreSQL 数据库

PostgreSQL 同样使用 TO_CHAR() 函数，其用法与 Oracle 非常相似。

示例：

-- 标准格式
SELECT TO_CHAR(order_date, 'YYYY-MM-DD') FROM orders;
-- 自定义格式
SELECT TO_CHAR(order_date, 'Month DD, YYYY') FROM orders;

在应用层面进行格式化（推荐实践）

对于大多数应用程序，尤其是Web应用和移动应用，更推荐的做法是在应用程序代码中处理日期格式化，这种遵循“关注点分离”原则的方法有许多优点。

为什么推荐应用层格式化？

1. 解耦与复用：数据库查询应专注于数据检索，保持其纯净性，将展示逻辑放在应用层，使得同一份查询结果可以被多个不同的视图（如Web页面、API接口、移动端）以不同格式复用。
2. 国际化支持：应用层可以轻松根据用户的语言和地区设置（Locale）来动态调整日期格式，美国用户看到 10/27/2025，而欧洲用户看到 27/10/2025,这在数据库层面实现起来非常复杂。
3. 灵活性：修改日期格式只需要改动前端或后端代码，无需触及数据库查询语句,降低了维护成本和风险。

实现示例（以 Python 为例）：

import datetime
# 1. 从数据库获取原始的日期时间对象 (通常是 datetime 对象)
# 假设 db_date 是从数据库查询得到的: datetime.datetime(2025, 10, 27, 14, 30, 0)
db_date = get_date_from_database()
# 2. 在应用层进行格式化
# 格式化为 "2025年10月27日"
formatted_date_cn = db_date.strftime('%Y年%m月%d日')
# 格式化为 "27/10/2025"
formatted_date_eu = db_date.strftime('%d/%m/%Y')
# 将格式化后的字符串传递给模板或API接口
print(formatted_date_cn)
print(formatted_date_eu)

如何选择最佳方案

选择哪种方法取决于你的具体场景：

场景	推荐方案	原因
快速生成一次性报表或数据导出	数据库层面格式化	无需修改应用代码，直接通过SQL得到结果，简单快捷。
复杂的Web/移动应用开发	应用层格式化	更好的架构设计，支持国际化，易于维护和扩展。
数据需要被多种不同客户端消费	应用层格式化	数据库返回标准格式，由各客户端按需转换，保证数据一致性。
数据库管理员或分析师进行数据探索	数据库层面格式化	在数据库客户端工具中直接使用格式化函数，方便查看和分析。

改变数据库中日期的显示格式是一个常见的展示层需求，虽然通过SQL函数在数据库层面可以直接实现，但从软件工程的长期角度看，将格式化逻辑置于应用层是更为健壮和灵活的方案，理解这两种方法的优劣，并根据实际业务需求做出明智选择,是高效处理数据的关键。

---

相关问答 FAQs

问题1：我修改了SQL查询，将日期格式化成了字符串，但导出到Excel后，Excel还是不把它当作日期，无法进行日期计算，怎么办？

解答： 这是一个常见问题，当您在SQL中将日期转为特定格式的字符串（如 YYYY/MM/DD）后，Excel可能会将其识别为普通文本,有两种解决方案：

1. 在SQL中使用标准格式：在SQL中将日期格式化为Excel最容易识别的文本格式，YYYY-MM-DD 或 YYYY/MM/DD，导出后，在Excel中选中该列，使用“数据”选项卡下的“分列”功能，在向导第三步中选择“日期”格式，并指定正确的年月日顺序（如 YMD）,Excel即可将其转换为真正的日期值。
2. 直接导出原始日期：如果可能，最好的方式是在SQL查询中不进行格式化，直接导出数据库的原始日期时间值，Excel通常能正确识别主流数据库的标准日期格式，导入后，您再通过Excel的“设置单元格格式”功能来统一调整显示样式。

问题2：我们的服务器和用户分布在不同时区，数据库存储的是UTC时间，如何在应用中正确展示为用户的本地时间？

解答： 这是处理全球化应用时的最佳实践,正确的处理流程如下：

1. 数据库存储：确保数据库中所有的时间戳都存储为UTC（协调世界时），推荐使用带时区信息的数据类型，如PostgreSQL的 TIMESTAMP WITH TIME ZONE,它能自动处理时区转换。
2. 应用层处理：在应用程序中，首先从数据库获取UTC时间，根据当前用户的时区信息（通常在用户个人设置中保存或通过请求头获取）,使用编程语言提供的时区库将UTC时间转换为用户的本地时间。
3. 格式化展示：将转换后的本地时间按照用户偏好的格式进行格式化并展示，在Python中可以使用 pytz 或 zoneinfo 库，在JavaScript中可以使用 Intl.DateTimeFormat 对象，它们都能非常方便地完成时区转换和格式化工作,这样做可以确保所有时间数据在全球范围内都是准确和一致的。