免费时长计算器
对时长进行加减运算。输入小时、分钟和秒以获取累计总和。
添加时长
条目
总计
工作原理
- 输入开始和结束时间: 输入两个时间(小时、分钟、秒)或从时间选择器中选择,以定义您要测量的范围。
- 加上或减去时长: 可选择将多个时间段串联起来 , 添加休息时间、减去暂停时段,或合并多个片段。
- 查看结果: 总时长以小时、分钟和秒显示。可直接复制或使用结果。
为什么使用时长计算器?
手动计算时长既繁琐又容易出错,尤其是在跨越午夜或处理多个片段时。无论您是在测量视频时长、计算可计费工时、衡量锻炼间隔,还是计算活动持续时间,时长计算器都能即时完成运算 , 包括跨越午夜或累加数十个时间段等边界情况。
功能特点
- 开始/结束时间输入: 输入或选择任意两个时间,即可计算它们之间的间隔。
- 多片段支持: 添加多个时间块,获取合并后的总时长。
- 跨越午夜: 正确处理跨越午夜的时长(例如,晚上 11:30 至凌晨 2:00 = 2 小时 30 分钟)。
- 小时、分钟、秒: 结果以完整精度显示,精确到秒。
- 即时计算: 无需点击提交按钮 , 更改数值时结果即时更新。
常见问题
如何计算跨越午夜的时间?
输入午夜之前的开始时间和午夜之后的结束时间。计算器会自动检测跨夜时段并返回正确的时长(例如,晚上 10:00 至早上 6:00 = 8 小时)。
我可以将多个时间段加在一起吗?
可以。使用多片段模式,您可以根据需要添加任意数量的时间块。这对于计算多次会话的总工作时长或累加视频片段长度非常有用。
时间输入应使用什么格式?
使用标准的 HH:MM 或 HH:MM:SS 格式。该工具接受 24 小时制时间,并自动转换为易读的时长。
ISO 8601 持续时间格式
ISO 8601-1:2019 是表示日期、时间和持续时间的国际标准。ISO 8601 中的持续时间看起来像 P[n]Y[n]M[n]DT[n]H[n]M[n]S:字面量 P(意为「period」周期),后跟任意年/月/日组合,然后是 T 分隔符,之后是小时/分钟/秒的时间部分。PT1H30M 是 90 分钟的咖啡休息;PT45S 是 45 秒;P3D 是 3 天;P1Y2M10DT2H30M 是 1 年 2 个月 10 天 2 小时 30 分钟。周有自己的指示符 P1W(与 Y/M/D 互斥)。
该标准是现代系统中持续时间的规范线路格式。PostgreSQL 将持续时间存储为 interval 类型,使用 ISO 8601 输入/输出。JavaScript 即将推出的 Temporal 提案(TC39 的 Stage 3,有望在 ES2025 中推出)通过 Temporal.Duration 与 ISO 8601 持续时间往返。Python 的标准 datetime.timedelta 默认不序列化为 ISO 8601,第三方包 isodate 填补了这个空白。time-interval 形式 2026-05-12T09:00:00/PT1H30M 表示「从 5 月 12 日 09:00 开始,持续 1h30m」,这就是日历 API(Google 日历、iCal、Outlook)在线路上发送的内容。
为什么 HH:MM:SS 算术让人犯错
如果你先转换为总秒数,添加 01:45:30 + 02:30:45 很容易:6,330 秒 + 9,045 秒 = 15,375 秒,转换回 04:16:15(15375 ÷ 3600 = 4 小时;1575 ÷ 60 = 26 分钟;余 15 秒)。人们犯错的地方:
- 忘记分钟和秒是模 60,而不是模 100。
00:45 + 00:20 = 01:05,而不是00:65。这是手工时间表数学中最常见的算术错误。 - 跨越午夜就像模运算一样。如果你的意思是「23:30 之后 2 小时是什么时间」,
23:30 + 02:00= 时间 01:30,但从 23:30 到第二天早上 02:00 的持续时间是 02:30。同样的输入,根据你是计算未来时间还是测量间隔,意义不同。 - 夏令时跳跃和回落。在美国太平洋时区将 24 小时加到
2025-03-09T02:30会得到2025-03-10T03:30,因为夏令时在那天开始,02:00–03:00 不存在。日历感知库处理这个;朴素的库会偏移一小时。 - 「加 1 个月」不是固定的秒数。一个月可能是 28、29、30 或 31 天。ISO 8601 明确将
Y和M的解析留给消费者,它是日历指针,而不是固定持续时间。大多数库(Luxon、Pythondateutil.relativedelta、Javajava.time.Period)夹紧到目标月份的最后有效日:2025-01-31 + 1 个月 = 2025-02-28。
夏令时和时区警告
如果持续时间跨越时区边界或夏令时转换,你必须决定是要「经过的挂钟时间」(秒表会显示的内容)还是「时钟差异」(显示如何变化)。它们在夏令时期间分歧。3 月 9 日当地时间 22:00 离开波士顿、3 月 10 日当地时间 01:30 在旧金山降落的航班,在空中经过了 6h30m(通过 UTC 计算),但由于时区偏移,时钟显示差异仅为 3h30m。修复方法是将两个时间戳锚定在 UTC 中并相减:endUTC.getTime() − startUTC.getTime()。IANA Time Zone Database(tzdb)是夏令时规则的规范来源,随每个浏览器和操作系统一起发布。墨西哥于 2022 年 10 月全国废除夏令时;巴西于 2019 年废除。美国自 2021 年起搁置 Sunshine Protection Act(阳光保护法案)以废除每年两次的切换,但尚未通过众议院。
可计费工时,0.1 小时惯例
律师事务所、咨询公司和自由职业者通常按 十分之一小时(6 分钟增量)计费:7 分钟的任务向上舍入到 0.2 小时计费,5 分钟的舍入到 0.1。该惯例可以追溯到 1950 年代后期的美国 BigLaw,当时物理时间表使用「0.1 列」来简化手工计算,并且它在数字时代仍然存在,因为它在短互动中有利于公司的收入捕获。一些公司使用 四分之一小时模型(向上舍入到最近的 15 分钟)。该模型实质上影响总账单:以十分之一计费的 16 分钟通话是 0.3 小时($300/小时收费 90 美元);以四分之一计费是 0.25 小时(75 美元);以 30 分钟块计费是 0.5 小时(150 美元)。30 分钟块是临床心理治疗中的惯例,其中 CPT 代码 90832(「16-37 分钟」)作为「30 分钟心理治疗」行计费。同时显示原始 HH:MM:SS 和四舍五入到十分之一的十进制小时涵盖了 90% 的可计费小时用例。
视频、音频和精确到帧的时间码
电影院和广播以帧而非秒来计算时间,因为物理胶片和数字编解码器使用它作为原子单位。NTSC 电视(美国、加拿大、日本、南美部分地区)以 30000/1001 fps ≈ 29.97 fps 运行;其「drop-frame」时间码 HH;MM;SS;FF(分号)通过每分钟丢弃 2 个帧号(每 10 分钟除外)来补偿 0.1% 的减速。PAL 电视(欧洲大部分地区、澳大利亚、亚洲大部分地区)以 25 fps 运行。电影院标准是 24 fps。彼得·杰克逊的《霍比特人》(2012)是第一部以 48 fps 的主要发行;李安的《比利·林恩的中场战事》(2016)以 120 fps 运行。Adobe Premiere、DaVinci Resolve 和 Final Cut Pro 都以项目选择的帧率显示时间码,专业的持续时间计算器接受 HH:MM:SS:FF 输入。YouTube 播放器章节使用 MM:SS;导出嵌入 ISO 8601(PT1M30S)。
运动和历史上的著名持续时间
- 勒芒 24 小时:自 1923 年起恰好 24 小时的比赛。总距离随天气和维修站策略而变化,但顶峰约 5,100 公里,获胜者的平均速度约 213 公里/小时。
- 马拉松:42.195 公里;世界纪录 2h00m35s(凯尔文·基普图姆,芝加哥,2023 年 10 月 8 日)。精英完成 2h-2h10m;休闲 4h-5h。
- 一级方程式大奖赛:根据 FIA 体育条例第 5.3 条,挂钟时间最长 2 小时。2011 年加拿大大奖赛因 2h05m 红旗雨停而以 4h04m39s 创下纪录。
- 板球测试赛:计划 5 天 × 6 小时比赛 = 跨越日历天数的 30 小时。有史以来最长(英格兰 vs 南非,1939 年 3 月)持续了 12 天,以平局结束,因为英格兰队的船要离开了。
- NHL 加时赛纪录:1936 年 NHL 半决赛第 1 场(底特律红翼 vs 蒙特利尔栗色)总共 176 分钟,其中 116 分钟加时,这是联盟历史上最长的比赛。
两个时钟问题:Date.now() vs performance.now()
如果你使用两种不同的时钟源计算持续时间,你可能会得到无意义的结果。JavaScript 公开了两种:Date.now() 返回自 Unix 纪元(1970-01-01T00:00:00Z)以来的 UTC 毫秒,但它跟随系统时钟变化,所以如果 NTP 在你的测量期间调整系统时钟,你会得到错误的持续时间。performance.now() 返回从页面导航开始的高分辨率时间戳,单调且不受时钟变化影响。对于「经过的实际时间」使用 performance.now();对于「挂钟」使用 Date.now()。Web Audio API 公开 audioContext.currentTime 以进行采样精确的音频计时,与系统时钟和性能时钟解耦。setTimeout(fn, 1000) 是「不早于 1000ms」,而不是「恰好 1000ms」;Chrome 将后台标签节流到最小间隔 ≥1000ms,事件循环可能延迟执行,操作系统挂起可能将间隔拉长到许多秒。
常见使用场景
- 视频编辑器汇总片段长度跨多个镜头(47×3.2s + 12×6.7s + …)。
- 自由职业者追踪可计费工时从会话日志(9:15-10:45、11:00-12:30、13:30-15:45 = 7h15m),转换为十进制小时用于发票。
- 项目经理估算总持续时间通过链接任务持续时间(设计 4 天 + 审查 1 天 + 开发 7 天 + QA 3 天 = 15 天)。
- 番茄钟用户汇总工作间隔以追踪一天的深度工作产出(5 × 25 分钟会话 = 2h05m 净工作)。
- 音乐制作人测量专辑播放时间通过汇总单个曲目持续时间;总计 ≤80 分钟以适合单张 CD。
- 播客主验证剧集长度与平台上限(Spotify 将剧集限制为 12 小时;大多数目录偏好 3 小时以下)。
- 厨师缩放食谱时间跨越准备、休息、烹饪和摆盘阶段(35 分钟准备 + 8 小时发酵 + 45 分钟烤制 = 9h20m)。
- 运动员汇总每周训练时间从训练日志确认体积目标。
- 直播运营者计划多段节目带休息和广告(开场 5min + A 段 25min + 广告 2min + B 段 30min + 结尾 3min = 65min)。
常见错误
- 将分钟或秒视为十进制。45 + 20 分钟是 65,进位为 1 小时 5 分钟,而不是「0:65」。总是转换为总秒数,求和,然后转换回去。
- 通过简单减法计算跨午夜持续时间。
02:00 − 23:30作为数字是负数;正确的答案(从 23:30 到第二天 02:00 的持续时间)是 2h30m。在减法之前给结束时间加 24h。 - 在跨日期持续时间中忽略夏令时。美国太平洋时区「3 月 9 日 23:00」+ 4 小时 =
3 月 10 日 04:00,而不是 03:00,因为 02:00–03:00 不存在。使用 UTC 算术或日历感知库。 - 将「1 个月」视为固定持续时间。根据月份,它是 28 到 31 天。对于经过时间算术,始终使用秒或天进行操作。
- 相信
setTimeout(fn, 1000)会在恰好 1000ms 后触发。浏览器会节流非活动标签(Chrome ≥1000ms),事件循环可能繁忙,操作系统可能挂起。对于高分辨率计时,使用performance.now()增量或requestAnimationFrame。
更多常见问题
如何将 HH:MM:SS 转换为计费的十进制小时?
将总秒数除以 3,600。02:45:00 是 9,900 秒;9,900 ÷ 3,600 = 2.75 小时。要四舍五入到最近的十分之一(BigLaw 6 分钟惯例),乘以 10,四舍五入,除以 10:2.75 → 27.5 → 28 → 2.8 小时。对于四分之一小时舍入,乘以 4,向上舍入,除以 4。
结果可以超过 24 小时吗?
可以。持续时间不是时钟时间;它可以是任何非负数小时。该工具将总数渲染为 HH:MM:SS,小时 ≥ 24(例如,一天半的 36:30:15)。如果你想要天/小时分开,将小时除以 24:36 小时 = 1 天 12 小时。
减去比加的多时的负持续时间怎么办?
当运行总数低于零时,该工具会显示带前导减号的结果(例如,−00:30:00)。负持续时间在「这次跑步比上周节奏低 1m12s」或「项目提前 2 天完成」等上下文中很有意义。
该工具是否处理精确到帧的视频时间码?
当前版本使用 HH:MM:SS 精确到秒。精确到帧的时间码(24、25 或 29.97 fps 的 HH:MM:SS:FF)尚不支持。对于帧级工作,规范工具是 Adobe Premiere 的时间码面板、DaVinci Resolve 和 Avid Media Composer,所有这些工具都能正确汇总 drop-frame 时间码。
我的输入会发送到任何地方吗?
不会。该计算器完全在你的浏览器中运行。你输入的小时、分钟和秒在 JavaScript 中求和,结果渲染到 DOM。无 fetch 调用,无分析,无日志记录。安全用于输入个人敏感持续时间,如医疗预约长度、可计费客户时间或私人活动日志。