Unix时间戳：秒、毫秒和错误的日期
四个输入，一个瞬间。了解时间戳为何会落在1970年或错误的日期上。
落在1970年1月的时间戳往往单位不对。数字1792069200是Unix秒；1792069200000是同一时刻的毫秒数。两者都不需要在转换前添加时区偏移。
打开时区转换器，展开粘贴日期或时间戳，粘贴任一数字并选择转换。检查表单下方的解释。两者都应生成2026-10-15T13:00:00.000Z。
同一时刻的四种写法
逐一尝试这些写法，或下载四个时间戳示例：
1792069200
1792069200000
2026-10-15T13:00:00Z
2026-10-16T00:00:00+11:00
最后一行已经是次日的午夜，但它仍代表同一时刻。其显式的十一小时偏移解释了差异。
工具将第一个数字解读为秒，第二个解读为毫秒。对于今天的日期，10位与13位数字是有用的线索，但并非时间戳的通用定义。此转换器拒绝猜测11位和12位数字输入，而不是猜测。它支持1900年至2100年的日期；它不是所有历史时间戳格式的解析器。
如果你在编写JavaScript，数字Date构造函数期望毫秒。MDN的Date参考记录了该单位。将秒乘以1,000是单位转换，不是时区调整。
检查日期和时钟
使用添加时区来包含你需要的城市。对于上述示例，测试结果为：
| 时区 | 本地日期和时间 | 该日期的UTC偏移 |
|---|---|---|
| UTC | 2026年10月15日 13:00 | +00:00 |
| Australia/Melbourne | 2026年10月16日 00:00 | +11:00 |
| Europe/London | 2026年10月15日 14:00 | +01:00 |
| America/New_York | 2026年10月15日 09:00 | -04:00 |
这些偏移属于示例日期。不要将它们复用为城市间的固定差异；夏令时可能改变间隔。对于重复性任务，请参阅cron和夏令时示例。
在任意时钟卡片内拖动会移动共享时刻，因此所有卡片会同步更新。复制所有时间也会复制日期和偏移。这对队友来说比单独发送“上午9点”更有用。
没有偏移的日期是另一种输入
粘贴2026-10-15T13:00并将未指定时区时，按以下时区读取设置为Australia/Melbourne。它变成2026-10-15T02:00:00.000Z，比第一个示例早十一小时。
没有出错：这次你提供了本地时钟读数，源时区提供了缺失的上下文。对于Unix数字或显式偏移，该源选择不会移动时刻。我的时区可以添加你设备的时区，但你的设备无法告诉你未标记的日志条目最初使用哪个时区。
在分享前解决歧义输入
工具故意要求你澄清几种输入：
10/11/2026 09:00可能表示10月11日或11月10日。请使用年-月-日格式的日期。2026-10-15 09:00 CST使用模糊的缩写。选择完整的源时区或提供显式的UTC偏移。2026-11-01T01:30在America/New_York中，当时钟回拨时会出现两次。请提供预期的偏移；仅凭本地时钟读数无法在两者之间选择。
我们在2026年10月15日检查了这些输入和四个等效时间戳，与工具的解析器进行了核对。转换输出和结果记录保留了确切值。自然语言解析因语言而异；当时间必须无歧义时，显式日期和偏移是更好的选择。