周末闲着没事，写了个py小脚本想按拍摄时间给几千张照片重命名，图以后翻看省事。吧哈哈哈
离谱话说
结果跑完一看，零八年去西北的、二二年去海边的一股脑全混一起了，时间线跟绕口令似的哈哈哈。
排查半天才发现exif里的时区没处理，datetime原样读出来当本地时间用，实际相机记的是utc，整差八小时。再加上有些老照片压根没exif，我图省事用了文件修改时间兜底，这下更乱了。
最险的是第一版直接os.rename没判断目标在不在，好在我习惯先备一份再跑，不然真的当场去世。
现在但凡动文件的脚本，我一律先dry run打印一遍对一对，确认无误才真改。备份加先打印，这俩习惯真救过我命。
你们有没有跑完脚本后背冒冷汗的时刻，来让我平衡一下哈哈
你这个"实际相机记的是utc"我得较个真。具体什么相机、哪年的机器先不论，单看EXIF规范：在EXIF 2.31（2016年）之前，DateTimeOriginal、DateTimeDigitized这些字段压根没有时区偏移位，绝大多数相机写进去的就是本地时间，不带任何offset。换句话说，默认情况下你拿到的是个裸字符串"2022:08:15 14:30:00"，无从判断它是utc还是本地。其实
严格来说所以那八小时偏差，根子不在"相机记了utc"这个前提（它记没记utc，你其实没法从裸datetime里看出来），而在于你给一个没有时区标注的时间安了一个确定的时区去解释。无论当初当成本地还是当成utc，只要和实际对不上，就会偏这八小时。
真要严谨，得去读OffsetTimeOriginal这个tag（2.31之后才加的）——有就按它换算绝对时间；没有的话，从数据完整性讲，你不能想当然假设它是utc，只能默认相机所在本地时区，否则一样错。你那批零八年的老照片基本不可能带这个tag，所以严格说，"相机记的是utc"这个判断本身就值得商榷。
顺带，用文件修改时间兜底，风险比你以为的还大：跨设备拷贝、从手机导出，mtime常常被刷成拷贝当天的日期，老照片一旦走兜底基本就丢真时间了。dry run救急是对的，但兜底字段得选准。
后来那批照片你们最后按什么标准定的时间？有offset的归offset、没offset的默认本地？
先被你那个"绕口令时间线"逗笑，零八年的西北和二二年的海边搅一块，这要发出来人家还以为你搞了场时空漫游。
说真的你这已经算稳的了，起码还知道先备一份。我前阵子理自己那堆照片也犯过浑，手痒写了个小脚本批量改时间，时区压根没管，跑完发现整段行程的日期全错位。也是靠备份捡回一条命，不然真得对着几千张图怀疑人生。
你现在的干法没毛病，dry run 加备份，下次就算翻车也是体面地翻。老照片没 exif 那块，用文件修改时间兜底确实是个大坑，基本都栽这儿。C’est la vie，照片嘛乱就乱点儿，翻到了都是回忆。
写脚本这胆子我是真服，几千张说动就动。
你这个八小时差，根因可能不单是"相机记的是utc"。EXIF 里的 DateTimeOriginal 按规范本来就不带时区，存的就是相机当时设的本地时间。也就是说"原样读出来当本地时间用"在多数相机上反而是对的，除非你那台机器本身被设成了 UTC。真要准，去读 OffsetTimeOriginal 这个标签（EXIF 2.31 才加的），它直接给偏移量，比如 +08:00，有这玩意就以它为准，没有再兜底。
更乱的其实是 mtime 兜底。EXIF 拍摄时间和文件系统修改时间是两把不兼容的尺子，混在一起排序等于拿摄氏度和华氏度硬加。老照片没 exif，我建议单独拎出来人工看，或者干脆跳过，别拿 mtime 去跟拍摄时间排一条线。
碰撞那块你只查了"目标在不在"，但重命名是整体映射。两张同秒拍的（连拍、手机夜景多帧合成）可能映射到同一个新文件名，这时候 os.rename 在 Windows 上直接报错、在 Linux 上直接覆盖，都不好玩。dry run 时把目标名做个计数，出现重复先拦下来。
其实我以前也栽过，整理完发现一排照片名字撞了，还好备了份。你这 dry run 加备份的习惯保持住，比任何校验都实在
以前我也图省事跳过备份，结果丢过一批东西。自那以后，动任何文件先复制一份成了肌肉记忆。
八小时这茬，踩过的人真不少。你以为是时区没处理，其实根子还更深一层：EXIF 里那条 DateTimeOriginal，早年的规范压根没给时区留位置。相机厂爱怎么写怎么写，有的记本地时间，有的记 UTC，还有的你出国玩没调机器，直接按出发地时区落了戳。光看 datetime 那个数字，它自己从不告诉你"我是哪边的钟"。所以这回差八小时，下回换台机器说不定差六小时、差半天，全看运气。
你拿文件修改时间兜底，这步其实最悬。mtime 这东西不老实，照片从相机拷到电脑、从旧盘倒到新盘、微信收一下再存，每过一道手，修改时间就跟着刷新。它记的是"文件啥时候落到你这磁盘上"，不是"快门啥时候按的"。老照片没 exif 常见，可一旦拿 mtime 去补，等于用上一道工序的痕迹当真相，越补越歪。
那会儿
话不能这么说不过你那两个习惯我是真服气。先备一份再跑、改之前 dry run 打印对账，看着笨，实则是救命绳。我多嘴补一句：除了备份，最好顺手留一份旧名到新名的对照表，哪天发现哪批排错了，不用翻整个备份也能原路退回去。再狠一点，按文件内容算个哈希去重，重名也不怕。慢慢来
别急
我前年也干过一桩糊涂事。整理家里老照片，图快直接拖进新文件夹，手一滑选成了移动不是复制，进度条走到一半我妈喊吃饭，我一关窗口，那批照片连影子都没了。话不能这么说还好后来从旧备份捞回来，打那以后动任何文件我都先 cp 再删，慢是慢了点，心里踏实。
这事吧
你们 dry run 救过命的，评论区接着讲，我搬板凳听。
你那个"相机记的是utc"先存个疑。EXIF的DateTimeOriginal按规矩是拍摄地当地时间，不带时区字段，相机大多记的是本地钟点。差八小时，八成是读取的库默认按UTC解析了，不是相机存的就是UTC。
拿exiftool或PIL的getexif去读，新规格带OffsetTime能给你±时差。简单说老照片没exif就别用mtime兜底，那只是拷贝下载的时间，跟拍摄时间半毛钱关系没有，硬塞进去才真乱套。
我前阵子归置家里老相册也翻过车，后来规矩改成先导出清单人工对一遍才动文件。
我年轻的时候也干过这类没头没脑的事。头回学摆弄电脑那阵，想给一摞老照片归置归置，手写了个批处理图省事，没留意文件名里带空格，命令一跑，整宿的活散得满地都是，第二天对着屏幕干坐了半晌。
后来就学乖了，凡是要动文件的，先在屏幕上一行行列出来过一遍，确认妥了才真动手。你这dry run的路数是对的，比当年的我稳当多了。那个utc差八个钟头，我头回撞上也懵过，还疑心相机出了毛病。能先备一份再跑，是福气，我见过的，多半是栽过一回才长记性。
我年轻那会儿可没你这好习惯，备份这种事总嫌多余。有一回也是整理东西，写了个批量改文件名的脚本，想着跑完就完事。说实话结果手一抖，路径写错了一级目录，几千个文件全给挪进一个临时夹子里，原目录一下子空了。慢慢来那会儿冷汗真就下来了。
后来还好机器没关，进程还在跑，我赶紧把剩下的截住，再对着清单一个个挪回去。从那以后我也学乖了，动文件之前先打印一遍，路径对上了才真动手。
你那个时区没处理、八小时整差一块的坑，挺典型的，多少人栽过。现在养成 dry run 加备份这俩习惯，往后能少遭不少罪。
读到你先备一份再跑，我松了口气。我从前也犯过懒，直接上，把一整文件夹旅行照改得面目全非，对着黑屏坐了半晌。后来也学乖了，先打印先备份，像出门前总要把门锁两遍才安心。
我懂这种后背发凉，上次没备份直接跑，吓出一身冷汗。现在动文件前必dry run一遍
你这个"相机记的是utc"我得较个真。EXIF里DateTimeOriginal那几个字段，在老标准下压根不带时区信息，相机通常是把自己设的本地时间直接写进去，只是没标注+8。所以严格说不是相机记了utc，是你的脚本把一段没有时区的本地时间当utc读了，那八小时是这么来的。
我之前也栽过，后来习惯先用exiftool把原始字段原样dump出来对一遍，看相机到底记的啥时区再动手。顺便，EXIF 2.31之后加了OffsetTime那几个标签专门存偏移量，碰上近几年的相机倒是能直接读出来 (￣▽￣)