旅行时如何检查电子日记的原始日期与显示时间
当你在跨时区旅行中撰写电子日记时，应用中显示的日期可能与你记忆中写作当地的日期不一致。请分别检查三项内容：原始记录时间及其 UTC 偏移量、应用显示的日记日期，以及你设备当前设置的时区。保持原始记录完好，并在依赖大规模备份之前先测试单条导出。这有助于你区分无害的显示变化与可能已被重写的时间戳。
为什么同一篇日记会显示两个日期
一个时间戳可以描述同一个瞬间，但在不同的本地时钟上呈现不同的读数。例如，2026-04-12T00:30:00+09:00 与 2026-04-11T15:30:00Z 描述的是同一个瞬间。日历日期之所以不同，是因为本地时间快于 UTC。RFC 3339 定义了带有表示 UTC 的 Z 或带有形如 +09:00 数值偏移量的时间戳；偏移量是时间戳用于确定具体瞬间的一部分。RFC 3339: Date and Time on the Internet: Timestamps
当应用程序按照设备当前所在时区呈现该瞬间时，显示内容也可能发生变化。技术日期系统通常存储一个瞬间，并将其解释为 UTC 或本地时间以供显示；设备的时区可以改变本地日期，而不会改变瞬间本身。MDN: Date - JavaScript
这种区别对日记非常重要，因为你希望用于浏览的日期可能是你撰写该日记所在地的日期，而应用可能会以你当前所在位置来显示同一个瞬间。切勿仅凭日期就推断日记应用采用的是哪种行为。请检查记录本身及其导出数据。
在更改设置前记录原始时间戳和偏移量
打开一篇最近在旅行时撰写的日记，记下日记详情中显示的准确日期和时间（如果可用）。寻找偏移量（+09:00、-04:00）或 UTC 标记（Z）。像 2026-04-12T00:30:00+09:00 这样的字符串比“4月12日凌晨12:30”包含更多信息，因为它明确指定了偏移量；当在系统之间迁移时，没有时区的日期和时间可能会产生歧义。RFC 3339 的时间戳格式包含偏移量，而未限定的本地读数本身无法确立偏移量。RFC 3339
如果应用仅显示友好格式的日期，请寻找条目信息面板、原始数据视图或导出选项。记录应用实际暴露出来的内容；不要仅仅因为应用能显示日期就假定它存储了时区。你还可以记下设备当前的时区设置以及你撰写该条目的地点。这些笔记能在不改动日记条目的情况下生成一份简短的比对记录。
偏移量与具名时区不能互换。数值偏移量表明在某一时刻本地时钟时间与 UTC 相差多少。而像 Asia/Tokyo 或 America/New_York 这样基于地点的时区则描述了特定位置随时间变化的时钟规则。这些规则可能会发生变动，包括夏令时调整，因此记录时的偏移量可能与设备当前的偏移量不同。IANA 维护着一个记录本地时间历史以及时区边界和夏令时规则变更的数据库。IANA: Time Zone and Daylight Saving Time Data
将日记日期与设备时区进行比对
在系统的日期与时间设置中检查设备当前的时区。记下时区名称或 UTC 偏移量，以及是否启用了自动时区检测。然后将条目的原始偏移量与设备当前时区进行比对。这是一种排查性的比对，并非证明应用更改了时间戳：显示的日历日期不同，可能只是针对当前时区转换了同一个瞬间。
一个实用的纸笔核对方法是将记录时的读数转换为 UTC。对于正偏移量，从本地时钟读数中减去该偏移量；对于负偏移量，加上其绝对值。在 2026-04-12T00:30:00+09:00 的例子中，减去 9 小时即可得到 2026-04-11T15:30:00Z。如果应用后来在 UTC−04:00 的时区中显示为 4 月 11 日晚上 11:30，这与比 UTC 晚 4 小时呈现的同一瞬间是一致的。日期虽有不同，但时刻并未改变。本例仅作说明，并不代表某一特定日记应用。
对于接近午夜的旅行日期，请比对完整的时间戳，而不仅仅是日历天数。仅含日期的视图会丢失区分本地日期标签与瞬间所需的时钟时间和偏移量。同样，以 Z 结尾的时间戳代表 UTC；除非你的设备设置为 UTC，否则不应将其作为本地时间读取。MDN: Date.prototype.toISOString()
进行单条导出测试
在更改设备设置或导出整本电子日记之前，先导出一条易于识别的条目。保持原始条目原封不动。如果应用提供选项，请使用能够保留详细日期信息的格式，然后在纯文本查看器中检查生成的文件或记录。检查它是否包含带有 Z 或数值偏移量的时间戳、显示的日期是否出现在单独的字段中，以及导出是否生成了带有辅助数据的额外伴随文件（sidecar file）。
将导出的时间戳与应用显示的内容以及你记录的撰写地点和设备时区进行比对。如果导出包含完整的时间戳和偏移量，请将其转换为 UTC 并比对具体瞬间。如果导出仅包含日期、本地时钟时间或无偏移量的值，请将该信息标记为不完整；切勿猜测缺失的时区。测试导出能告诉你该特定应用和导出格式提供了什么。它并不能代表所有其他导出方式的表现。
谨慎对待文件系统日期。已下载文件的创建或修改时间可能反映的是下载时间，而非撰写日记条目的时间。Google 针对相册导出的指南为这种区别提供了一个具体例子：操作系统可能会在下载时分配一个新的文件时间戳，而原始时间戳仍保留在嵌入式元数据中。该指南针对的是照片和视频导出，因此无法确立日记应用的行为；但它确实说明了为什么仅凭文件的外部日期并不能替代对内容的核查。Google Photos Help: How to Download Your Google Data
决定保留什么以及接下来做什么
利用测试结果来选择低风险的下一步行动。如果原始条目详情和导出数据都保留了记录日期和偏移量，请保留该导出作为参考，并继续正常使用该应用。如果应用显示发生了变化，但完整时间戳保持一致，请注意这表明应用只是在展示本地化渲染结果。如果导出遗漏了偏移量或给出了不同的瞬间，请保持原始数据不变，并在编辑前查阅该应用自有的帮助材料或支持指引。
当该日记允许你编辑日期时，编辑可能会替换原始信息或创建一个新版本；各应用的行为有所不同。在调整任何内容之前，请在应用中保留原始记录，并单独保留那一份单条测试导出。如果你确实做出了修改，请记录下修改的内容和原因，以便日后阅读时能够区分记录时的原始信息与你偏好的浏览日期。避免通过修改设备时钟来强行获得所需日期：这会更改其他应用使用的系统设置，且其本身并不能告诉你日记存储的时间戳是否准确。
对于日历天数很关键的未来条目，可以在条目正文中添加简短的地点或本地日期附注，例如“写于东京，当地日期：4月12日”。这是一项人工标注，不能替代时间戳。如果应用日后在另一个时区呈现该条目，它能为你提供可见的参考依据。确认单次导出能够保留你所需的细节后，如果你的目标是备份，则可以对其余日记重复导出流程。
实际的检查步骤很明确：保留原始条目，将其时间戳和 UTC 偏移量与应用显示及设备时区进行比对，并在信赖备份前核查单条导出。当转换后日历日期有所偏移但瞬间仍然吻合时，你看到的很可能只是时区渲染。当偏移量缺失或瞬间不符时，请先暂停编辑并寻求针对该应用的指引。