日期与时间工具：时间戳转换与工作日计算
这个大类目前有一个工具：时间戳转换。它和还没有中文版的日期差、工作日计算属于同一件事 —— 把一个日期、一段时长或一个时刻，放到日历上正确的位置。
日期与时间大类下的工具
时间戳
- 时间戳转换 —— Unix 时间戳与日期时间互转。明确说出按秒还是按毫秒读、另一个读数是什么，同时给出 UTC、本机时区和你选的时区，并处理负时间戳、2038 边界，以及夏令时里「不存在」和「出现两次」的本地时间。
浏览器端 · 不限次数
工具页地址不随分类改变：分类只是导航，换分类不会让任何链接失效。 这也是本站把分类与 URL 分开的原因 —— 已经进过搜索引擎和收藏夹的地址，不该因为一次归类调整就跳转或失效。
时间戳的第一道坎：它到底是秒还是毫秒
Unix 时间戳是"从 1970 年 1 月 1 日算起过了多少个单位"，而这个单位要么是秒、要么是毫秒， 光看那串数字看不出来。十位数几乎总是秒，十三位数几乎总是毫秒 —— 但"几乎总是"这四个字很危险： 把毫秒当秒读，日期会跑到五万年后；把秒当毫秒读，日期会掉回 1970 年 1 月，而两个结果都排版得很正常。
所以这一页的做法是把假设说出来：它先按位数规则判断，然后明确告诉你"我按秒读了"， 同时把"如果按毫秒读会是什么日期"并排给出。两者都合理时，它不替你选；两者都不合理时， 它也不会硬给一个答案，而是把两个读数都列出来让你回原始数据里确认。
几个真实会撞上的边界
1970 年之前：负的时间戳是合法的，它表示 1970 年之前的时刻，工具会正常换算并标注出来， 而不是当成非法输入。2038 年边界：有符号 32 位整数能装下的秒数在 2038 年 1 月 19 日用尽， 老系统在这之后会回绕成 1901 年 —— 如果你的时间戳越界了，工具会把"回绕后会读到什么"一并算给你， 因为那正是你要排查的那个现象。夏令时：本地时间在切换那天可能"不存在"（跳过去的那一小时） 或"出现两次"（回拨的那一小时），这两种情况都会单独说明，并同时给出两侧的时刻。
这些边界不是炫技：它们正是"时间戳为什么看起来不对"最常见的几个原因。
这个大类接下来会补什么
按搜索需求，日期与大类里排在前面的还有：日期差（两个日期之间隔了多久， 按年/月/日与总天数两种口径）、工作日计算（跳过周末，并支持你自己贴节假日）、 年龄计算与时区换算。它们的共同点是只做日期算术：不需要任何外部数据表， 节假日的具体日期由你自己填 —— 这也是本站不做"内置节假日表"的原因， 一份写死的表对大多数访客都是错的，而且会自信地错在截止日期上。
该用哪一个
站内其它内容
时间戳很少单独出现，通常后面还跟着这些页面。
- 在线工具箱 —— 本站全部工具的总入口，以及它们的分类。
- JSON 格式化 / 校验 —— 时间戳所在的那份数据本身，出错时给出行号列号。
- Base64 编解码 —— 同一次排查的另一半：编码过的字符串里到底装了什么。
- 免费简历评分 —— 如果这段数据其实是你的简历，直接看它会在哪一步被卡。
常见问题
- 时间戳转换会上传我输入的内容吗？
- 不会。整页脚本只 import 一份纯函数模块，换算全部在这个页面里完成：没有发往服务器的请求、没有日志、关掉标签页就没了。也因此它不限次数 —— 一次换算和一百次换算对我们的成本都是零。
- 为什么非要我选"秒"还是"毫秒"？自动判断不行吗？
- 可以自动判断，本站也默认自动判断，但关键在于它会把判断结果和另一个读数都写出来。位数规则只是概率：十位当秒、十三位当毫秒在绝大多数场景成立，可一旦你的数据来自不常见的系统，猜错就是"日期格式完全正确、内容完全错误"。把假设摆在明面上，比默默猜一个更省事。
- 2038 那个问题对我的数据有影响吗？
- 如果你的时间戳在 32 位有符号整数范围内，就没影响。越界时工具会指出它越界了，并算出"被回绕成 32 位之后会读成什么日期"——1901 年 12 月 13 日那一类结果，正是老系统在 2038 年之后会显示的东西。
- 时区数据是从哪儿来的？会过期吗？
- 来自浏览器原生的 Intl 时区数据，本站不打包任何时区表。好处是它随浏览器更新而更新（夏令时规则变化时不需要我们发版），代价是极老的浏览器可能只认得很少的时区 —— 那种情况下页面会如实说明，而不是给你一个默认时区。
- 为什么没有"日期差"和"工作日"？
- 因为按"出厂即双语"的节奏，它们在英文侧已经排上了，中文侧还没做。本站不放指向英文页的链接：中文访客点过去读不懂，那样的链接比没有更糟。做完一个，这里就多一个。
这个大类下的工具全部跑在你自己的浏览器里：你输入的内容不会发给我们， 页面上的广告是它们的收入来源。另见隐私说明。