01
分清数据库列和接口属性
visits.visit_time 与 urls.last_visit_time 是常见的原始字段；扩展 API 的 lastVisitTime 却使用 Unix 毫秒。本页不凭数字位数猜格式，较短整数也可能合法，必须先确认数据来源。
日期与时间
WebKit 时间戳转换看清最后一位微秒
每行输入一个 Chrome 数据库时间戳，或带 Z／明确偏移的日期；结果统一显示 UTC，并列出 Unix 对照。
WebKit 时间戳转换
输入
结果
输入仅在当前浏览器中处理，不会发送到服务器。
选项
Chrome 数据库纪元：1601-01-01 UTC；每个单位为 1 微秒。
每行一个有符号十进制整数，或 YYYY-MM-DDTHH:mm:ss[.1–6 位小数]Z／±HH:mm。换算为 UTC 后须在 0001–9999 年内。
零值可算出纪元日期，但在 Chromium 中可能表示未设置；64 位有符号整数的最小／最大值为无穷哨兵，不生成日期。
UTC 固定显示六位小数。Unix 秒和毫秒向下取整，并分别保留非负的微秒余数。
最多 1,000 个物理行和 100,000 个 UTF-16 代码单元。去除行首尾空白；空行报错。
只有每行都能得到日期时才可反向；请先处理错误行和无穷哨兵。
输入内容或载入示例以开始。
WebKit 时间戳转换适合核对 Chrome 历史记录导出中的长整数。请从原始字段复制完整数字：如果表格软件已经把末位四舍五入，再精确的转换也无法找回丢失的微秒。
这里的 WebKit 是这类 Chrome／Chromium 数据库计数的常见叫法，不代表所有浏览器接口都从 1601 年计时。先确认来源字段，再看换算出的日期，能避开“数字看起来像时间戳”的误判。
为什么用 WebKit 时间戳转换
相差一微秒，结果仍可区分
WebKit 时间戳转换把 11644473600000001 换成 1970-01-01T00:00:00.000001Z，反向操作仍保留末位的 1。六位小数始终可见，便于核对只显示毫秒的日期查看器没有展示出来的差异。
坏行留在原位，便于回查
批量里混入一个非数字值，其余行照常换算。结果保留原文和物理行号，不会删除失败项后把后面的记录向上挤。导出报告时，成功日期与错误说明仍能逐行对应原始数据。
先核对字段，再核对偏移和余数
02
日期必须写明时区
反向换算请加 Z 或 ±HH:mm，即使电脑本身设为 UTC 也一样。示例随当前方向变化，点击后先出现替换预览；超过六位的小数会报错，不会悄悄截掉尾数。
03
注意结果何时刷新
默认停顿 350 毫秒后自动计算，关闭开关即可用按钮或 Ctrl/Cmd+Enter 手动执行。修改输入立即禁用旧结果导出；反向须全批都有日期，应用后可一次撤销并恢复之前的结果。
同一时刻，同时看三种 Unix 单位
整数原文不会变成浮点数
Chrome 时间戳的当前计数已超过 JavaScript 安全整数上限。计算使用整数运算，JSON 中的精确计数保留为字符串，避免报告被再次解析时丢失奇数末位；来源已经丢失的精度则无法修复。
秒和毫秒都有余数
WebKit 转 Unix 先减去 11644473600000000 微秒，再计算较粗的单位。报告给出完整 Unix 微秒，以及向下取整的秒、毫秒和各自的微秒余数，方便把商和余数重新组合验证。
负值也有明确方向
1601 年以前的有效日期对应负 WebKit 计数。1970 年前一微秒的 Unix 秒为 -1，余数为 999999 微秒，而不是把除法向零截断后误显示为零秒。日期仍受本工具的日历范围限制。
一千行可逐条追踪
最多接受 1000 个物理行及 100000 个 UTF-16 单元。界面先显示 50 行，每次可再显示 50 行；复制与下载始终包含全量 JSON，保留每行的原始输入、解释和错误说明。
计数格式与字段含义要分开看
- 只处理一种纪元和单位
- 不自动识别 Unix、JavaScript、FILETIME 或 Safari 格式。FILETIME 同样从 1601 年计时，但每单位是 100 纳秒；现代 WebKit 接口也不一定使用本页格式，performance.now 更是相对时钟。
- 零值不等于真实的历史事件
- 0 会附带 possibleNull 提示，其 1601 年结果仅是算术换算。-9223372036854775808 和 9223372036854775807 作为 Chromium 无穷哨兵单独列出，不生成日期或 Unix 值，也不推断业务状态。
- 可显示日期范围有限
- 有限日期规范化为 UTC 后必须在 0001 年至 9999 年内。这是本页显示范围，不是 64 位整数或 Chromium 的储存范围。普通有限值超界会产生该行错误，其余合法行仍可计算。
- 不猜时区，不修补日期
- 日期要含秒及 Z 或 ±14:00 内的偏移。不接受未知偏移 -00:00、无效日期、闰秒、24:00 或七位以上小数；不支持自然语言日期、命名时区和夏令时推断，也不会悄悄舍入。
- 只接收逐行的值
- 不读取 History／Cookies 数据库，不请求浏览历史权限，不提取 SQL 列或抓取网址。科学计数、十六进制及带引号的 JSON 数字会报错；行首尾空白可忽略，但空白行保留为错误，不会被自动删掉。
- 覆盖输入前先预览
- 示例、清空和反向操作都先展示替换内容、行数和字符数，点击应用才生效。一次撤销同时恢复原输入、方向和结果。含错误或无穷哨兵的批次不能反向，避免只保留成功行而丢失其他记录。
WebKit 时间戳转换常见问题
Chrome 把这些数字存在哪里？
常见位置包括 History 数据库的 visits.visit_time、urls.last_visit_time，以及 Cookies 数据库的 creation_utc、expires_utc 等字段。请先确认数据库版本和字段说明；本页只换算粘贴的值，不会读取你的浏览器文件。
为什么从 1601 年开始？
Chromium 的 base::Time 沿用 Windows 纪元，即 1601-01-01 UTC。它与 Unix 纪元相差 11644473600000000 微秒，转换时必须先扣除这段差值，不能只把一个长整数除以一百万。
这些列里的 0 是什么意思？
Chromium 的零时间可表示未初始化。直接计算会得到 1601 年，本页因此同时显示算术日期和可能未设置的提示。仅凭零值，无法判断会话 Cookie、过期规则或一次访问是否真实发生。
如何把 Chrome Cookie 中的时间戳换成日期？
确认是原始微秒字段后，选择 WebKit → 日期并粘贴整数。读取 UTC 结果，再结合来源字段含义判断。不要把扩展接口返回的秒或毫秒值直接套用这一换算，也不要忽略零值的特殊提示。
这种格式与 Windows FILETIME 相同吗？
纪元相同，单位不同：这里是微秒，FILETIME 是 100 纳秒，同一普通时刻的 FILETIME 数值是这里的十倍。微秒时间戳不能仅靠名称归类，应选用与来源单位相符的转换工具。
结果与预期不同？