时长换算
毫秒到天数互转，同时给出人类可读的复合写法。
语法范围以 Go 标准库的 time.ParseDuration 为参照：支持 ns、µs、ms、s、m、h 六个单位、可带小数、可带正负号、可以把多段直接串起来写（2h45m10s、1.5h、−45m），Go 本身不接受天以上的单位，因为「天」在有闰秒和夏令时的世界里不是定长。本工具在此之上做了三处扩展，并且在提示区说明清楚：一是加入定长的 d（86400 秒）与 w（604800 秒）以及中文单位（纳秒、毫秒、秒、分、小时、天、周），二是接受播放器与数据库常见的冒号写法——两段 1:30 读作「分:秒」即 90 秒，三段 1:30:00 读作「时:分:秒」，秒后可以带小数（0:05:30.5），三是能读 ISO 8601 的 P2DT3H 形式。纯数字没有单位时按秒解读（3661 即 3661 秒），这是为了顺手，和 ParseDuration 会直接报错的做法不同，工具会在提示里说明这一假设。
每行一个输入，成功的行输出六行换算值：毫秒、秒、分钟、小时、天、周，最后一行是中文复合写法（2d3h4m5s → 2 天 3 小时 4 分 5 秒），复合写法从天往下取整、余数落到毫秒，关掉开关可以只要数字。小数位可调 0–9（默认 3），值大到 10²¹ 毫秒以上或小到当前精度位以下时自动改走科学计数法，所以 1 纳秒显示为 1e-6 毫秒而不是被抹成 0。内部数值用双精度浮点存毫秒，纳秒级小数在约 100 天（9.0e9 毫秒）以内保得住，再大就会失去纳秒位。所有失败行列出原文和原因，例如「不认识单位「fortnight」」并附可用单位清单；天和周按定长口径，不涉及时区、夏令时与闰秒，全部计算在浏览器本地完成。
时长换算怎么用
- 把混合写法统一成毫秒：每行一段，例如 90m、1.5h、2d3h4m、3600s、500ms 一起贴进来，得到同一张毫秒标尺上的可比数值，适合汇总剪辑片段或工期。
- 秒数换成人话：输入 3661 得到 1 小时 1 分 1 秒，输入 183840 得到 2 天 3 小时 4 分；输出同时给出 0.02128 天这类十进制读法，方便按天折算成本。
- 处理时间码与 ISO 时长：1:30:00 按「时:分:秒」读作 5400 秒，1:30 按「分:秒」读作 90 秒，P2DT3H、2小时30分 也能直接读；要表达 90 秒请写 90s，别只写 90。
常见问题
为什么裸数字 90 不算成 1 分 30 秒？
因为「90」本身没有说明单位，而把它当作秒是工程上最常见的默认（毫秒时间戳差值、ffprobe 的 duration、Unix sleep 参数都以秒为单位）。如果你的场景是「分:秒」，请写成带冒号的 1:30，工具明确读作 90 秒；如果你要的是毫秒，写 90ms。为了避免误读，只要输入里出现了纯数字，提示区就会顶出这条假设，并提醒改写成 90s、1m30s 或 90000ms 里你想要的那一个。
为什么没有月和年？1 天为什么敢写成 86400 秒？
月和年的长度不固定：28 到 31 天、平年 365 天、闰年 366 天，还取决于具体日期与时区，折算成秒必须先知道「从哪天到哪天」，那是日期差计算而不是时长换算。天和周则是定长口径：本工具按 1 天 = 86400 秒、1 周 = 604800 秒处理，忽略闰秒（国际地球自转服务不定期插入的那一秒）与夏令时导致的 23/25 小时自然日。需要严格按日历推进的，请用站点里的日期差工具，它会考虑真实的年月日长度。
1.5h 和 90m 结果一样吗？纳秒这种小数会不会丢精度？
一样：两者都折成 5,400,000 毫秒，输出六行数值完全相同，区别只在解析出的写法标签。小数值方面，工具内部用双精度浮点表示毫秒，1 纳秒是 1e-6 毫秒，0.004 秒精确等于 4 毫秒；受限于 53 位尾数，纳秒位大约在 9.0e9 毫秒（约 104 天）以内可靠，超过就会退化。当你把小数位调到 0 时，1 纳秒那行会走科学计数法而不是显示 0，这是刻意让「极小值」不会静默消失。