我知道FAT32格式的文件系统以本地时间而不是UTC时间记录文件修改时间的时间戳。
但是，如果设备使用没有时区*的日期时间将文件记录到FAT32 SD卡，则SD卡认为它正在接收什么TZ？
我的猜测是：
- SD卡使用SD卡格式化的任何时区
- 或者-SD卡记录时间(无TZ)，当该文件复制到计算机时，计算机会说：">啊，它来自FAT32卡，必须在我的本地时间！">
对规范源的奖励。
编辑：初步测试显示#2。
- 将SD卡格式化为Fat32，并在12:45创建一个文件并弹出
- 更改计算机时区
- 插入SD卡：文件将显示12:45上午
- 在新时区重新设置格式，创建一个12:50的文件
- SD卡将读取12:50，无论您将其插入哪个TZ
- 但是，如果您在安装SD卡时更改TZ，则时间将更改
因此，与其称之为本地时间，不如将FAT32文件时间戳称为"TZ不可知">
我有一个三星HMX-Q10视频摄像头，可以在设置中设置时区和夏令时。显然，它在SD卡上存储的时间是UTC，这是一个令人头疼的问题，因为我在将来把SD卡放进电脑时(显然需要当地时间)编辑了一些牢固记录的文件。
我不清楚如何解决这个问题，因为很明显，同一个SD卡可能会在几个不同的设备中使用。除了对着镜头谎报时区，我看不出有什么其他选择。这有点麻烦，因为当夏令时发生变化时，我无法打开"夏令时"指示器。
因此，FAT32中存在以UTC存储的设备。除非你是唯一一个这样做的人，否则这是有道理的。
让我们看看什么是PC"显示"；对我来说！
我的系统是"；Windows 7专业版"；，只是与"；Locales"；德国。今天是2022年9月12日。法定时区是"；CEST"；(中欧夏令时间)，或者换句话说；UTC+02:00"；。
现在是当地时间08:58。我用我的手机(诺基亚E71，操作系统"Symbian")拍照，在DS卡(不是手机的内部存储)上创建了一个文件。不出所料；explorer"；示出了"；基准"=2022年9月12日和"；Uhrzeit"=08:58。好的
我的手机配置为自动与提供商的时间同步。因此，它会自动切换到夏令时。
现在我把这个手机和我的电脑连接起来(USB，模式"Massenspeecher")。我的电脑看到一个USB设备连接到电脑上。计算机的文件浏览器告诉我：文件系统是FAT32，有趣的文件属性是：
- Aufnahmedatum："；2022年9月12日08:58">
- Ersteldatum："；2022年9月12日06:58">
- Aenderungsdatum："；2022年9月12日06:58">
对于非德国读者：
- 在图片内发现的exif标签"；当这张照片已经被拍摄时
- 创建文件的日期和时间
- 文件最后一次修改的日期和时间
因此，创建时间和上次修改的时间似乎是过去的2小时；似乎WINDOWS假定这是来自时区的数据"；UTC+00:00")。"；exiftool"；，用参数"…"执行-原始日期时间-文件修改日期"显示，我们以前看到过：exif标签＝"；2022年9月12日08:58"；并且修改日期＝"；2022年9月12日06:58"；。
现在，我将文件从手机复制到计算机的一个本地磁盘上，该磁盘的文件系统也是FAT32。SD卡留在手机中；它没有插入计算机SD卡插槽！)WINDOWS的文件资源管理器向我展示了我们感兴趣的属性：
- Aufnahmedatum："；2022年9月12日08:58">
- Ersteldatum："；2022年9月12日09:11"；(复制时)
- Aenderungsdatum："；2022年9月12日06:58">
- "exiftool"：和以前一样
现在我切断了计算机的所有网络连接(网络电缆已断开)，因为从现在起，我不喜欢干扰"；真实的"；世界，那里的时间是连续的"；runing"；和以前一样。
我把电脑的日期改为2022年11月11日。现在，WINDOWS系统认为，我大了60天减1小时，当前时区应该是"0"；CET"；，这是德国法定的冬季。对不起，我只假设这个细节。我真的没有在电脑上检查时区！)
现在我让文件资源管理器刷新显示的信息。哎呀！移动电话文件的时间戳显示为
- Aufnahmedatum："；2022年9月12日08:58">
- Ersteldatum："；2022年9月12日07:58">
- Aenderungsdatum："；2022年9月12日07:58">
- "exiftool"：和以前一样
这个文件的副本，位于我的本地磁盘上，现在显示
- Aufnahmedatum："；2022年9月12日08:58">
- Ersteldatum："；2022年9月12日10时11分
- Aenderungsdatum："；2022年9月12日07:58">
- "exiftool"：和以前一样
现在，我删除复制的文件并再次复制它。我选择了另一个目标目录；希望删除的文件不会受到干扰。这个"；新的"；副本在文件资源管理器中显示为：
- Aufnahmedatum："；2022年9月12日08:58">
- Ersteldatum："；11.11.2022 09:24"；(复制时的系统时间)
- Aenderungsdatum："；2022年9月12日06:58">
- "exiftool"：和以前一样
最后，我将系统日期设置回"；真实的"；2022年9月12日。
这个实验告诉我，WINDOWS文件资源管理器并不是简单地"；显示"；，它在大容量存储器中发现了什么；计算"；
WINDOWS不会修改exif数据。(它们是图片的一部分。)
我如何解释我所看到的？WINDOWS是否假定大容量存储器("外部"one_answers"内部")都有时间戳；在"；另一个时区，并且该时区是"0"；UTC+00:00"？请记住；exiftool"；在任何情况下都显示了"；2022年9月12日06:58"；，在我手动更改系统日期后，没有任何更改。
试图理解，发生了什么，我发现了一篇关于"；文件时间"；在里面https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times
"。。。FAT文件系统以本地时间记录磁盘上的时间。GetFileTime从FAT文件系统检索缓存的UTC时间。当它变为夏令时时，GetFileTime检索的时间为一小时，因为缓存未更新。重新启动计算机时，GetFileTime检索的缓存时间是正确的。FindFirstFile从FAT文件系统中检索本地时间，并使用时区和夏令时的当前设置将其转换为UTC。因此，如果是夏令时，FindFirstFile会考虑夏令时，即使您转换的文件时间是标准时间">
我们手下的前辈记得，MSDOS的文件系统只有FAT，并且总是以本地时间存储时间戳。时间戳总是显示为已存储。这个"；概念"；这并不是一个好主意，因为没有预料到会出现一个国际网络的世界。但在当地，一切似乎都很好。
真的很好吗？
一个晚上工作的人呢？他用大约每5分钟发生一次的协议创建文件，例如在熔化盗窃期间？秋天，当他从夏令时切换回来时，他创建了12个新的协议文件，这些文件在计算机中似乎比存储设备上已有的文件更旧。在使用本地时间时，02:00:00到02:59:59之间的3600秒中的每一秒似乎都存在两次。德国法律将其命名为"；A-Stunde"；以及"；B-Tunde"；。但FAT32无法区分它。
钢铁公司不能停止工作一个小时(因为炼钢是一个不能中断一个小时，只能中断几天的过程，通常在圣诞节和新年之间)。因此，这家公司不得不安装另一个(基于solaris、unix、…的)操作系统。
因为FAT32的文件系统没有每个文件的时区信息的位置，所以没有机会将时间戳的语义转换为传统的"；当地时间"；。(或者必须破坏使用兼容性。)
很久以后，NTFS被发明了，但为时已晚。
为什么时间戳被存储为"；当地时间"；一方面，但另一方面，NOW在检索时被转换为UTC？客户不喜欢这样，即使他们不融化偷窃。。。
因此，在未来，我可能会通过一个修改后的实验来继续我的研究。
这些观察使我得出他的总结：
- FAT32不存储任何时区信息您将找到时间值，即设备决定存储的内容。(我的相机总是存储本地时间的值。)
- "上次修改时间戳"one_answers"文件创建时间戳"是文件系统的一部分(此处：FAT32)。"拍摄照片的时间戳"是图片文件的一部分
- WINDOWS 7不"显示"这三个值，但"计算">。显示的值显然只是在某些情况下正确，但一般来说是不正确的
- 如果您需要true和未修改的值，请执行而不是使用WINDOWS的文件资源管理器！要阅读此信息，您可以使用"exiftool"；(Phil Harvey)，您可以在此处获取：https://exiftool.org/index.html
考虑到FAT32及其前身的历史，在文件保存或格式化中添加时区的概念是非常陌生的。
与DOS类似，时间是本地时间，所以很自然。
我怀疑我是否能找到一个与这些设计决策(或者更准确地说是缺乏设计)现代的规范来源。
因此，为了回答您的问题，文件保存时间很可能是本地时间，但以后的操作系统可能会决定改变这种做法。没有标准的方式来存储FAT32设备的TZ，所以你可以折扣该选项