使用方法
日期格式化转换器是「填日期、选格式、点转换」三步：
- 「日期」选或填年-月-日，演示值 2024-01-15。
- 「时间」填时:分:秒，演示值 09:30；只想转日期可留 00:00。
- 「目标格式」挑一种（横线、斜杠、中文、美式、紧凑、时间戳或 ISO），点「转换格式」，或在任一输入框按 Enter，结果进上方结果框，按「复制结果」整段拿走。
- 想还原演示值按「载入示例」：日期 2024-01-15、时间 09:30、格式 YYYY-MM-DD HH:mm:ss。
日期格式化转换器能解决什么
它解决「同一天要写成不同样子」的麻烦，适合三类场景：
- 日志与接口对齐：后端要
2024-01-15T09:30:00Z，前端表格要2024/01/15，文件名要20240115。一个源日期生成全部，避免手打错一位。 - 跨系统搬运：美式系统用
MM/DD/YYYY（01/15/2024），欧式用DD-MM-YYYY（15-01-2024），中文文案用2024年01月15日。转换后直接复制进对应系统。 - 时间戳换算：需要 Unix 秒 1705311000 或毫秒 1705311000000 时，比自己心算 epoch 更稳；ISO 8601 适合 API 与数据库字段。
本页不做的事：不做时区换算（统一按 UTC，避免歧义）；不解析自然语言日期（如「下周二」）；不处理农历。需要农历请换对应工具。
原理和变量
① 用了哪个具体函数：拆字段用 Date.UTC(年, 月-1, 日, 时, 分, 秒) 拿到毫秒，再 getUTC* 取回各分量；时间戳用 Math.floor(ms / 1000)；ISO 用 toISOString()。
② 关键参数为什么这样取：统一按 UTC 解释输入输出，是为了让同一串「2024-01-15 09:30」在任何电脑上得到同一时间戳，不受用户时区漂移影响。月份在 JS 里是 0 基（1 月=0），所以传入时减 1。
③ 遵循哪个标准：格式约定沿用 ISO 8601 的记号（YYYY/MM/DD、T、Z），时间戳沿用 Unix epoch（1970-01-01 UTC 起算的秒/毫秒）。这些是日志、数据库与接口的事实标准。
④ 输入怎么变成输出：演示输入 2024-01-15 09:30 → UTC 分量年 2024、月 1、日 15、时 9、分 30；按 YYYY-MM-DD HH:mm:ss 拼成 2024-01-15 09:30:00；Unix 秒 = Date.UTC(2024,0,15,9,30,0)/1000 = 1705311000；ISO = 2024-01-15T09:30:00.000Z。
⑤ 边界与阈值：日期必填且须是合法日历日（如 2024-02-30 会被拦下并提示）；时间缺省按 00:00:00；格式未选时默认 YYYY-MM-DD HH:mm:ss。年份范围受 JS Date 限制（约 1970～9999 安全）。
⑥ 常见误用的正确解释：时间戳不是「当天第几秒」，而是距 1970-01-01 UTC 的总秒数；秒与毫秒差 1000 倍，混用会大 1000 倍。美式 MM/DD/YYYY 与欧式 DD-MM-YYYY 只看数字会混淆，必须看分隔与位置。
完整示例（数值仅作演示）
保持演示值：日期 2024-01-15、时间 09:30:00。
- YYYY-MM-DD HH:mm:ss → 2024-01-15 09:30:00
- YYYY/MM/DD → 2024/01/15
- YYYY年MM月DD日 → 2024年01月15日
- MM/DD/YYYY → 01/15/2024
- DD-MM-YYYY → 15-01-2024
- YYYYMMDD → 20240115
- Unix 秒 → 1705311000
- Unix 毫秒 → 1705311000000
- ISO 8601 → 2024-01-15T09:30:00.000Z
这九组结果与下方对照表完全一致，可三处核对。
输入范围与对照表
日期格式化转换器的对照表固定演示时刻 2024-01-15 09:30:00（UTC），列出同一时刻的全部写法：
| 格式 | 结果 |
|---|---|
| YYYY-MM-DD | 2024-01-15 |
| YYYY/MM/DD | 2024/01/15 |
| YYYY年MM月DD日 | 2024年01月15日 |
| MM/DD/YYYY | 01/15/2024 |
| DD-MM-YYYY | 15-01-2024 |
| YYYYMMDD | 20240115 |
| YYYY-MM-DD HH:mm:ss | 2024-01-15 09:30:00 |
| Unix 秒 | 1705311000 |
| Unix 毫秒 | 1705311000000 |
| ISO 8601 | 2024-01-15T09:30:00.000Z |
同一时刻在不同格式下数字差异很大，但都指向 2024-01-15 09:30:00 UTC；复制前请确认下游系统要的是哪一种。
结果边界和舍入
舍入位置：日期各分量按两位数补零（如 1 月显示为 01），年份用四位；时间戳是整数秒/毫秒，不做小数截断以外的舍入。
什么时候会拒绝计算：日期为空或不是合法日历日（如 2 月 30 日）、时间格式错时，会给出具体中文提示后才继续，不会输出乱码。
时区与精度：本页统一按 UTC，所以结果和你本地时钟可能差几小时；若需本地时区时间戳，请在结果上自行加减偏移。秒级时间戳精度到秒，毫秒级到毫秒。
结果性质：这是纯文本格式变换，不含任何历法推算或时区智能，只作格式规范化用途。
常见问题
为什么我本地时间和结果对不上？
本页按 UTC 解释输入，结果为该时刻的 UTC 写法；你本地若在东八区，真实本地时间是 17:30。若想用本地时区，需在时间戳上自行加减偏移。
Unix 秒和毫秒差多少？
差 1000 倍。秒是 1705311000，毫秒是 1705311000000。接口若要求毫秒而你传了秒，时间会回到 1970 年附近，务必确认单位。
MM/DD/YYYY 和 DD-MM-YYYY 怎么区分？
看分隔前后的位置：美式月在前（01/15/2024），欧式日在前（15-01-2024）。当日月都 ≤12 时容易混淆，复制前请核对系统规范。
时间不填会怎样？
留空或 00:00 时按当天零点处理，时间戳指向 2024-01-15 00:00:00 UTC，纯日期格式则不受时分影响。
能转农历或星期几吗？
不能。本页只做公历的格式变换，不含农历与星期推算。需要星期或农历请换对应日期工具。
年份能填多大？
安全范围约 1970～9999。更早或更晚的年份超出 JavaScript Date 稳定区间，结果可能不可靠，建议分段处理。
ISO 8601 末尾的 Z 是什么？
Z 表示零时区（UTC）。它表示这个时间戳不含时区偏移，是国际标准写法，最适合接口与数据库存储。
我的输入会被保存或上传吗？
不会。全部转换在浏览器内完成，刷新即清空；点「转换格式」时没有任何网络请求发出。