macOS Photos 导入照片日期错误：最后竟是 12/24 小时制的问题

声明：本文由 GPT 结合实际经历和个人写作风格 Skill 生成。Cover Photo 引自 Unsplash。

这个问题在我的 Mac 上存在了好几年。

我的照片一般先在 Lightroom Classic 中完成编辑，再导出 JPEG，最后加入 Photos 并同步到 iCloud。按理来说，Photos 应该使用图片 EXIF 中的原始拍摄时间；但在我的 Mac 上，它总是把 Lightroom 的导出时间当成拍摄时间。

比如一张下午 4:11 拍摄、晚上 11:45 导出的照片，进入 Photos 后就会被放到晚上 11:45。图片不算少的时候，每次都要手动「调整日期与时间」，实在很烦。

我原本以为这又是一个只能靠 workaround 共处的 Apple bug。最后真正修好它的操作却简单得有点荒谬：

系统设置
→ 通用
→ 日期与时间
→ 打开一次「24 小时制」
→ 再切回原来的 12 小时制

就这样，Photos 恢复了正常。

不过在找到这个开关以前，我和 GPT 已经把图片元数据、Lightroom、Photos 图库、iCloud、用户账户和一堆缓存几乎查了个遍。整个过程很适合写下来：一方面，这个 bug 显然不只发生在我这里；另一方面，最终解法和表面症状之间几乎没有任何直觉联系。

先说结论

如果你的情况与下面几项相符：

  • 图片里有正确的 DateTimeOriginal；
  • Photos 却采用文件创建、修改或 Lightroom 导出时间；
  • Finder 的「添加到照片」和 Photos 内的「文件 → 导入」都会出错；
  • 同一文件在新的 macOS 用户中导入正常；

可以优先试一次：

  1. 打开「系统设置 → 通用 → 日期与时间」；
  2. 切换「24 小时制」；
  3. 退出并重新打开 Photos；
  4. 导入一张从未导入过的测试图片；
  5. 正常后，再切回自己习惯的时间格式并复测一次。

Apple 的文档只说明这个开关控制 12/24 小时显示；「语言与地区」则决定 macOS 和 App 使用的日期、时间等格式。Apple 并没有说它会影响 Photos 读取 EXIF，更没有公开承认这个 bug。Apple：日期与时间设置；Apple：语言与地区设置

因此，目前能够实证的是「切换开关修好了导入」；至于它究竟刷新了哪一项 preference 或 cache，仍然未知。

问题到底是什么

这次使用的样本是 Lightroom Classic 15.4.1 导出的一张 Sony JPEG：

文件名：DSC07067.jpg
尺寸：6192 × 4128
相机：SONY ILCE-6700
原始 RAW：DSC07067.ARW

第一次直接把图片传给 GPT 时，上传流程把它压缩成了 2048 像素长边，并清空了 EXIF、XMP 和 IPTC。后来我把原文件装进 ZIP 再上传，才拿到可以检查的原始字节。

这是这次排障中的第一个小经验：如果要让别人检查图片元数据，最好传 ZIP，不要直接把图片扔进聊天软件。很多平台会把「图片」当作需要展示的媒体，而不是需要原样传输的文件。

原始 JPEG 里有两组含义完全不同、但各自内部高度一致的时间。

第一组是拍摄时间：

EXIF DateTimeOriginal       2026:07:29 16:11:23
EXIF SubSecTimeOriginal     454
EXIF OffsetTimeOriginal     +08:00

EXIF DateTimeDigitized      2026:07:29 16:11:23
EXIF OffsetTimeDigitized    +08:00

XMP CreateDate              2026-07-29T16:11:23.454+08:00
XMP Photoshop DateCreated   2026-07-29T16:11:23.454+08:00

IPTC DateCreated            20260729
IPTC TimeCreated            161123+0800

第二组是 Lightroom 导出或保存 JPEG 的时间：

EXIF/IFD0 ModifyDate        2026:07:29 23:45:03
XMP ModifyDate              2026-07-29T23:45:03+08:00
XMP MetadataDate            2026-07-29T23:45:03+08:00
XMP HistoryWhen             2026-07-29T23:45:03+08:00

ZIP 保存的文件修改时间同样是晚上 11:45。

换句话说，这个文件没有「日期写乱了」。它只是同时、正确地记录了两个事实：

时间 含义
2026-07-29 16:11:23.454 +08:00 相机拍摄时间
2026-07-29 23:45:03 +08:00 Lightroom 导出/保存时间

Adobe 自己也明确区分这几类字段：调整 capture time 会更改 Date Time Original，多数相机的 Date Time Digitized 也会随之变化；普通的 Date Time 则表示照片最后更新时间，不会跟着拍摄时间一起改。Adobe：Lightroom Classic 元数据基础

因此，Photos 把 23:45 当作「拍摄时间」，不是 Lightroom 不会写 EXIF，也不是文件缺少时区。正常情况下，它应该选择 16:11。

如果要自己检查一张文件，ExifTool 比 Preview 更适合，因为同名日期可能同时存在于 EXIF、XMP、IPTC 和文件系统中。建议使用：

exiftool -a -G1 -s -Time:All "/path/to/photo.jpg"

这里的 -a 会显示重复标签，-G1 会显示标签所属分组，-s 则显示实际标签名。ExifTool 的文档也把 DateTimeOriginal、CreateDate 和 ModifyDate 作为不同字段处理；不要只看到一个「Date」就假设它一定是拍摄时间。ExifTool：Shortcuts Tags；ExifTool：MWG Tags

GPT 搜到了相似案例，但最开始仍然没有答案

确认文件本身没问题后，GPT 开始广泛搜索类似报告。很快就找到了几条高度相似的 Apple Community 帖子。

2022 年，有用户报告照片明明带着 2009 年的 DateTimeOriginal 和 CreateDate，Photos 却把它导入到 2022 年。其他人拿同一文件测试时一切正常；发帖者在新的 macOS 用户中导入，也立刻恢复正常。Apple Community：Photos is not using Exif original Date Time when I import

2024 年又有人报告了几乎相同的问题，而且已经持续数年：原用户错误，新用户正常。讨论中的建议仍然是安全模式、新图库和新用户，用来区分问题究竟位于图库、账户、缓存还是登录项。Apple Community：Photos on Mac not importing with correct EXIF date

这些案例至少说明了一件事：Photos 是否正确选择 EXIF 日期，不完全由文件本身决定。用户环境也可能参与其中。

但「用户环境」实在是一个太大的范围。它可能是 Photos 偏好、图库数据库、沙盒容器、后台服务、区域格式，或者某个从旧版 macOS 一路升上来的残留状态。知道它是 user-specific，并不等于知道该改什么。

一层层排除

最开始我怀疑的是导入入口。

Finder 的「分享 → 添加到照片」经过 Share Extension，有可能没有把原文件完整交给 Photos。但我改用 Photos 内的「文件 → 导入」，结果完全一样。于是可以排除「只有分享菜单出错」。

接下来是图库。Apple 官方建议按住 Option 启动 Photos，创建一个额外图库用于测试；新图库不是 System Photo Library，也不会自动出现 iCloud 内容，所以很适合做隔离实验。Apple：创建额外的 Photos 图库

结果是：

环境 导入结果
当前用户 + 原图库 错误
当前用户 + 全新空图库 仍然错误
新 macOS 用户 + 全新图库 正常

这一组对照非常关键。它基本排除了「原图库数据库单独损坏」，也说明 macOS 和 Photos 并非普遍无法解析这张 JPEG。否则同一台 Mac 上的新用户不应正常。

我还试了重置 com.apple.Photos 偏好、移走 Photos 的沙盒容器和缓存，全部无效。Apple 的 Photos Repair Library 也主要负责检查并修复图库数据库不一致；当前用户里的全新空图库都会复现，自然不太像它能解决的问题。Apple：Photos Repair Library

到这里，问题已经从「Photos 为什么读错 EXIF」缩小成了「这个用户账户中，究竟有什么状态让 Photos 读错 EXIF」。

很具体，也很没用（

先接受 workaround：只改 Photos，不改原图

因为我不想迁移到新用户，GPT 后来给出的现实方案是：正常导入，再用 osxphotos 把原文件的 EXIF 拍摄时间拉回 Photos 数据库。

osxphotos timewarp --compare-exif --verbose
osxphotos timewarp --pull-exif --verbose

第一条只比较 Photos 与原始 EXIF 的日期、时间和时区；第二条才实际更新 Photos 中的记录。--pull-exif 不会把 Photos 数据写回 JPEG，因此 Lightroom 的导出时间仍然保留。osxphotos：CLI / timewarp

这点对我很重要。我当然可以把文件的 ModifyDate、FileModifyDate 全部改成 DateTimeOriginal，这样 Photos 即使选错字段，最终也能得到「正确答案」。但拍摄时间和导出时间本来就是两个不同事实；为了绕过一个导入 bug 而抹掉后者，不是我想要的结果。

osxphotos timewarp --pull-exif 的确成功修正了选中照片。后来我还把它包装成 Shortcuts，放进：

Photos → 服务 → Fix Photos Capture Time

这样至少不用每次打开 Terminal 粘命令。Apple 官方支持把 Shortcut 放到 macOS 的 Services Menu 中运行。Apple：在其他 App 中运行 Shortcut

这中间还有一个很典型的 AI 小插曲：GPT 最初给出的命令带了一个不存在的 --selected 参数，被本机的 osxphotos timewarp --help 当场打脸。正确行为是让 timewarp 读取 Photos 当前选择，或者使用 --uuid-from-file 明确指定资产。AI 很适合帮忙搜索、整理和建立排障假设，但具体到会修改图库的命令，还是应该以本机版本的 --help 和项目文档为准。

不过这仍然只是 workaround。更重要的是，timewarp 会通过未公开方式直接修改 Photos 图库数据库；项目作者明确警告它可能损坏图库，并建议事先备份、小范围测试。它适合修正已经导错的旧照片，不适合被描述成毫无代价的官方解决方案。osxphotos 的风险说明

真正的突破：一条有关 12/24 小时制的回复

在很长的搜索结果里，GPT 最后提到了一条看起来相当离谱的线索：某些设备上的 Photos 日期选择错误，可能与「区域默认时间格式被手动改过」有关。

这条 2025 年的 Apple Community 讨论原本讲的是 iPadOS 18.5 和 AirDrop。用户准备了一张测试图，故意让几个时间字段互不相同：

FileCreateDate       2025:07:05 05:05:05
FileModifyDate       2025:07:06 06:06:06
ModifyDate           2025:07:07 07:07:07
DateTimeOriginal     2025:07:07 07:07:07
CreateDate           2025:07:07 07:07:07

当设备所在地区默认使用 24 小时制、但用户手动关闭 24 小时制时，Photos 采用了 FileModifyDate；恢复地区默认的 24 小时制后，下一次 AirDrop 又会选择 DateTimeOriginal。发帖者还表示，类似现象似乎也出现在 iOS/iPadOS 17/18 和 macOS 13/14。Apple Community：The photo app on all my devices do not work with EXIF of photos

这不是 Apple 工程团队的说明，只是用户在 Community 中做的对照实验。但它与我的情况有一个非常可疑的共同点：同一文件在一个用户中错误，在另一个使用默认设置的新用户中正常。

我在澳大利亚，一直使用默认的 12 小时制。看到这条线索后，我打开了 24 小时制，再导入一次照片——正常了。

更神奇的是，我随后把设置切回 12 小时制，Photos 仍然正常。

Holy…

这也推翻了一个看似直接、但并不准确的结论：不是「Photos 不支持 12 小时制」，也不是「澳大利亚必须改用 24 小时制」。如果 12 小时制本身有问题，切回去以后 bug 应该立刻复现。

更合理的解释是：当前用户账户里的某项日期/时间格式状态曾经陈旧、不一致或损坏；切换 12/24 小时制迫使 macOS 重新写入相关偏好，或者刷新了 Photos / Foundation / ImageIO 使用的 formatter cache。Photos 原先可能因为这个状态而无法正确接受 DateTimeOriginal，随后回退到 FileModifyDate 或其他修改时间。

但这部分只能算机制推断。Apple 没有公开 Photos 导入时各日期字段的完整优先级，也没有说明 12/24 小时显示格式为何会影响 EXIF 解析。Apple 的 ImageIO 确实提供读取 DateTimeOriginal 等 EXIF 属性的标准接口，但究竟是 Photos、ImageIO、Foundation 还是某个用户级后台服务出了问题，目前没有证据可以继续定位。Apple Developer：kCGImagePropertyExifDateTimeOriginal

为什么之前那些操作都没用

找到触发点后，前面的现象反而都能解释了。

现象 更合理的解释
分享和「文件 → 导入」都错 两条入口最终使用了相同的用户级日期解析状态
新图库仍然错 问题不在 .photoslibrary 数据库
新用户正常 新用户拥有干净的区域与时间格式状态
安全模式无效 不是普通第三方登录项或扩展
重置 Photos 偏好、容器无效 相关状态位于 Photos 沙盒之外
打开 24 小时制后恢复 这个开关触发了相关用户级状态刷新
切回 12 小时制仍正常 最终显示制式不是根因，旧状态才是

严格来说，我们仍然没有拿到那个「坏掉的 preference key」，也没有进程日志证明缓存究竟在哪里。因此我不会把「切换开关刷新了 formatter cache」写成已经确认的内部机制。

这次能确认的只有三层：

  1. 文件层： EXIF、XMP、IPTC 中的拍摄时间完整而一致；
  2. 环境层： 问题只在原用户出现，新用户正常；
  3. 触发层： 切换一次 12/24 小时制后，新导入恢复正常，切回原格式也没有复发。

剩下的是很强的推断，但仍然是推断。

如果你也遇到了同样的问题

不建议一上来就删除 Photos 容器、重建 iCloud 图库，或者迁移整个 macOS 用户。可以按下面的顺序来。

1. 先确认不是「最近保存」的排序

在 Photos 中选择照片，按 Command-I。Apple 将这里显示的信息描述为照片拍摄的日期与时间；如果信息窗口本身就是导出时间，才是本文讨论的问题。Apple：查看 Photos 中的照片信息

2. 检查原文件的所有时间字段

exiftool -a -G1 -s -Time:All "/path/to/photo.jpg"

重点看：

[ExifIFD] DateTimeOriginal
[ExifIFD] CreateDate
[IFD0]    ModifyDate
[XMP-xmp] CreateDate
[XMP-xmp] ModifyDate
[System]  FileModifyDate

如果 DateTimeOriginal 缺失，或者 EXIF、XMP、IPTC 里的拍摄时间彼此冲突，就不能直接套用本文结论。Lightroom 导出时也要避免只保留 Copyright 一类的精简元数据；Adobe 的导出说明中，All Except Camera Raw & Camera Info 会排除包括日期时间在内的相机 EXIF 信息。Adobe：导出文件的 Metadata 选项

3. 直接切换一次 24 小时制

系统设置 → 通用 → 日期与时间 → 24 小时制

切换后重开 Photos，用一张从未导入过的文件测试。确认正常后，可以切回原本偏好的格式，再测试第二张。

不要使用 Photos 已经导入过的同一资产判断结果：旧记录可能已经把错误日期写进图库，Photos 也可能把文件识别成重复项目。

4. 如果仍然不行，再隔离图库与用户

  • 当前用户的新图库正常：检查或修复原图库；
  • 当前用户的新图库仍错、新用户正常：继续检查用户级区域、日历和日期时间格式；
  • 所有用户、所有图库都错：回到文件元数据或导出设置；
  • 只有某一种导入入口错：再检查 Share Extension 或该入口传递的文件表示。

这比直接重装系统有效得多，也更容易知道每一步究竟排除了什么。

5. 历史错误照片再考虑 osxphotos

系统设置恢复后，已经导错的照片通常不会自动重新读取 EXIF。可以先选少量照片并比较：

osxphotos timewarp --compare-exif --verbose

确认无误后再执行：

osxphotos timewarp --pull-exif --verbose

使用前请备份图库。不要加 --use-file-time，否则缺少 EXIF 的文件会重新回退到文件修改时间；也不要把 --push-exif 与这里的「只改 Photos 记录」混为一谈。

最后

这次排障最离谱的地方，不只是「拨一下 24 小时制开关就好了」。

在找到它以前，所有证据都指向一个模糊但合理的结论：这是当前用户特有的 Photos / 媒体服务状态异常，公开手段很难修，最好做一个自动化 workaround。这个判断并没有错，osxphotos 也确实解决了当时的实际问题；只是后来出现了一条更具体的新证据，把根因范围从「某个用户级状态」缩到了「日期与时间格式」。

技术排障大概就是这样：先接受证据能支持到哪里，然后在新证据出现时把旧结论改掉。没必要为了显得一开始就很聪明，假装那些绕路没有发生。

至于为什么一个本应只影响显示格式的开关，会让 Photos 改变 EXIF 日期字段的选择——这个问题，只能留给 Apple 解释了。

参考资料