免费在线时间单位换算工具,支持 ns、μs、ms、s、min、h、day、week、month、year 共 10 个常用时长单位双向即时换算。输入任意一个数值后,其他单位结果会实时同步更新,适合接口延时、脚本超时、工时统计、学习计划、SLA 口径统一和报表整理。需要特别注意的是,本页处理的是“时长”而不是“日期时间”,其中 month 固定按 30 天、year 固定按 365 天换算,不会自动处理闰年、时区、日历月份长度和具体起止日期。所有计算都在浏览器本地完成,数据不上传服务器。
时间换算处理的是“时长”而不是“时刻”。像 30 秒、90 分钟、72 小时、3 周、6 个月这类值,都表示持续了多久,因此可以使用固定比例线性互转。相反,某年某月某日某时某分这种日期时间并不是本页处理对象,因为它们会受到时区、夏令时、闰年和具体月份天数影响。
在短时延场景里,ns、μs、ms、s 是最常见的四组单位。程序性能、硬件响应、数据库耗时、动画帧和网络延时经常在这些单位之间来回切换。统一单位后,同一份监控图、日志和文档更容易横向比较,也能减少数量级误读。
在日常和运营场景里,分钟、小时、天、周是最实用的表达层级。比如会议 45 分钟、值班 12 小时、交付 3 天、冲刺 2 周。做报表时常常需要把不同来源的时间字段统一成同一个量级,这样求和、平均和排序会更稳。
本页里的 month 和 year 采用固定口径:1 month = 30 天,1 year = 365 天。这种写法适合做估算、报表和预算周期统一,但不适合用来推算真实日历上的到期日、工资结算日或请假天数。只要场景牵涉到具体日期,就应该改用日历逻辑处理。
时间和频率经常配套出现。时间是一个周期有多长,频率是单位时间里发生多少次。做周期、采样、振动或刷新率分析时,先把时间统一成秒,再做后续公式推导,通常是最清晰也最不容易出错的做法。
先看你是在处理程序延时、日常时长,还是报表中的周月年估算,再决定用哪组单位最顺手。
| 单位层级 | 代表单位 | 最常见场景 | 使用提醒 | 本页支持 |
|---|---|---|---|---|
| 超短时延 | ns / μs / ms | 程序性能、接口延时、硬件定时、采样周期 | 适合高精度时长,做系统参数配置时很常见 | 支持 |
| 通用时长 | s / min / h | 脚本超时、会议时长、训练计划、工时统计 | 最适合日常沟通和大多数业务系统字段 | 支持 |
| 中长期周期 | day / week | 排班、交付周期、备份窗口、SLA 报表 | 适合做计划和汇总,容易横向比较 | 支持 |
| 固定估算口径 | month / year | 预算、报表、订阅周期、长期计划估算 | 本页固定 month=30天、year=365天,不是日历计算 | 支持 |
| 日期时间逻辑 | 具体日期 / 时区 / 闰年 | 到期日、账期截止、时区换算、请假天数 | 这类问题不是固定比例换算,不能用本页直接处理 | 不支持 |
本页适合 90 分钟、72 小时、6 个月这种持续时长,不适合 2026-07-01 到 2026-08-01 相差多少天这类日期逻辑。只要出现具体起止日期,就不要把线性换算当成日历计算。
许多系统接口、数据库字段、监控面板和超时参数最终都以秒或毫秒为准。先统一单位,再录入配置或做公式推导,能显著减少数量级错误。
如果你在文档或报表里使用 month 或 year 的换算值,最好在旁边注明“month=30天,year=365天”。这样别人看到结果时,不会误以为你已经考虑了真实月份长度和闰年差异。
同一份周报、工时报表或 SLA 汇总里,最好不要一部分写分钟、一部分写小时、一部分写天。先统一成同一个层级再统计,可读性和准确性都会更高。
尤其是 ms、μs、ns 这类差一个量级就会出大问题的场景,建议先保留原始换算精度,最后展示时再按需要保留小数位。
本页当前支持 10 个时间单位:ns、μs、ms、s、min、h、day、week、month、year。它们分别覆盖程序与电子系统里的超短时长,以及日常和报表里常见的分钟、小时、天、周、月、年口径。需要注意的是,当前页面不支持 fortnight、decade、century 或 millennium 这类更长周期单位。
1 秒 = 1000 毫秒(ms) = 1000000 微秒(μs) = 1000000000 纳秒(ns)。这组换算非常适合做接口延时、数据库响应时间、动画帧时长、采样周期和程序 sleep 参数对照。比如 1500 ms 就等于 1.5 s,500 μs 则等于 0.5 ms。
1 分钟 = 60 秒,1 小时 = 3600 秒,1 天 = 86400 秒,1 周 = 604800 秒。做定时器、缓存过期、脚本超时、SLA 窗口和数据保留时间时,很多系统最终都要求你填秒或毫秒,这时先把时长统一到秒通常最稳妥。
本页固定使用 month = 30 天 = 2592000 秒,year = 365 天 = 31536000 秒。这是为了把“时长换算”做成稳定的线性关系,方便报表和估算。它不代表真实日历月份长度,也不会自动处理 28/29/30/31 天差异、闰年或具体起止日期。
不能。本页只处理纯时长数值的单位换算,例如 90 分钟换成小时、72 小时换成天。它不会读取开始时间和结束时间,也不会计算两个日期之间相差多少天,更不会处理 UTC、本地时区、夏令时或倒计时日历逻辑。
90 分钟 = 1.5 小时,72 小时 = 3 天。这类换算非常常见于排班、课程安排、运维窗口、工单响应和健身训练计划中。本页支持直接输入任意整数或小数,实时看到小时、天、周等多个口径结果。
因为本页把 month 固定按 30 天处理,所以 1 month = 30 day ≈ 4.2857 week。真实日历中的“一个月”可能是 28、29、30 或 31 天,因此如果你在算合同起止日、账期截止日或请假天数,应使用专门的日期逻辑而不是本页的线性 month 换算。
可以。像 -0.5 s、1.25 h、0.008 ms 这类带符号或带小数的时长都可以正常换算。负值常见于做时间差、偏移量或相对提前/延后标记,而小数则常见于接口延时、训练时长和实验数据。
因为当前代码实际只支持 10 个单位:ns、μs、ms、s、min、h、day、week、month、year。本页 SEO 和说明现在已经严格对齐这个真实支持范围,不会再承诺 decade、century、millennium 这类页面里实际没有的单位。
它们经常一起出现,但不是一回事。时间换算处理的是“一个周期持续多久”,频率换算处理的是“每秒发生多少次”。如果你手里是周期时长,例如 20 ms、500 μs,通常应先统一成秒,再按 f = 1/T 转成 Hz。需要做 Hz、kHz、MHz、GHz 之间换算时,请配合频率换算工具使用。
可以。页面加载完成后,所有时间换算都在浏览器本地执行,没有网络请求、没有服务端日志、没有表单提交。你的工时、脚本超时、实验记录和业务规则配置不会上传到服务器,关闭页面后输入即清空。
这些基准值在工时、排班、SLA 和脚本配置里最常用。
| 基准值 | 常见等值 | 典型场景 |
|---|---|---|
| 1 s | 1000 ms = 1000000 μs = 1000000000 ns | 接口响应、动画时长、超时配置 |
| 1 min | 60 s | 会议、训练、短任务计时 |
| 1 h | 60 min = 3600 s | 工时、班次、窗口时间 |
| 1 day | 24 h = 1440 min | 日报、备份、交付周期 |
| 1 week | 7 day = 168 h | 排班、冲刺、周报 |
| 1 month | 30 day = 720 h | 订阅期、报表估算 |
| 1 year | 365 day = 8760 h | 年度预算、长期规划 |
不是所有时间数据都适合放在同一层级,选对单位会让表格更好读。
| 场景 | 更适合的单位 | 原因 |
|---|---|---|
| 接口延时、数据库耗时、动画时间 | ms 或 μs | 方便观察细小差异,也更接近系统监控和日志口径 |
| 脚本超时、定时任务、会议和训练计划 | s、min 或 h | 既能保留精度,又适合人类阅读和配置 |
| 工时统计、班次安排、SLA 窗口 | h 或 day | 便于汇总总时长和对照人力安排 |
| 项目计划、交付节奏、备份周期 | week 或 month | 更适合做中长期节奏表达,但要注明 month 的固定口径 |
| 年度预算、订阅年限、长期估算 | year | 汇总表达更简洁,但本页的 year 固定按 365 天处理 |
本页所有时间换算都在你的浏览器里完成。你输入的工时、超时配置、实验时长、SLA 数值和报表参数不会离开你的设备 — 没有网络请求、没有服务端日志,关闭页面后输入即清空。对于内部流程配置和敏感业务参数,本页不会采集或存储任何内容。
