_finddata_t结构是否将系统时间返回time_write或受到会话时区的影响?

我在这里指的是_filefirst()_findnext() API的文档

这些API以_finddata_t结构返回文件信息。 我需要从time_write元素访问文件修改时间。 虽然文档说时间以UTC格式存储(这是一个时间戳)。 文件没有说明这个时间是代表当地时间还是UTC时间。 在我看来, time_write不会返回UTC时间,而是它的值受系统时区设置的影响。

我的问题是 – time_write是否返回以UTC时间戳表示的本地时间?

编辑1在这里,我解释了我正在试图了解的东西。 我的系统在IST时区。 现在,有一个窗口显示的文件emp10.ibd

创builddate – 10/21/2016 10:51 AM

修改date – 2016年10月21日上午10:51

我用纪元转换器来找出它的结果如下的纪元时间戳 –

本地时间到时代转换

现在,如果我从_finddata_t结构检索了time_write结构中的time_write元素, _finddata_t结构已经被_findnext()返回给同一个文件, emp10.ibd 。 我期望返回的时间戳应该接近

时间戳1477027260,如上图所示。

但是我得到了time_write为1477043509

如果我再次使用时代转换器,我得到以下 到当地时间的时代

我想了解为什么在上面共享的两张图片中,GMT有4:30小时的时差? IMO时间戳应该几乎相同。 我在这里错过了什么?

Edit2对于那些要求示例代码的人。 在这里,我粘贴另一个职位的链接,一年前我提出了相同的原因,但情况是有点不同,我指的是_stati64结构。 那时我没有进一步解决问题。 现在很明显,_finddata_t和_stati64 API受到_tzset环境variables的影响,正如Harry在本文中提到的,而FILETIME结构不是。

Solutions Collecting From Web of "_finddata_t结构是否将系统时间返回time_write或受到会话时区的影响?"

当地时间为UTC加上地理位置偏差加上潜在的季节性偏差。 UTC时间戳没有这样的偏移量。

在这个特定的情况下,确切的格式是自1970-01-01T00:00:00Z即1970年1月1日,在UTC的午夜之后的秒数。

要进一步排除故障,接下来我使用GetFileTime API检索FILETIME结构中的文件修改时间,并将时间转换为UTC时间戳。 我按照我在电脑上设定的时间得到了时间。 我期待着一样的。

此时我开始研究通过perl脚本执行程序的方式。 我发现perl脚本将时区设置为GMT-1
由于我的电脑是在GMT+5:30 +04:30 hrs时区,所以我用原来的文章中提到的+04:30 hrs的结果。

因此,我想总结一下我的经验: _finddata_t strcut的结果受会话中设置的时区影响,但是FILETIME struct的结果不受会话中设置的时区的影响,而是根据系统时区。 因为我正在使用FILETIME struct检索一次而使用另一个使用_finddata_t strcut导致的问题。 花了我48小时才找到这个有趣的观察。

为什么会发生? 也许哈利在评论部分提供了答案。我在这里粘贴一样 –

在Perl中更改时区可能会导致设置TZ环境变量,这会影响C运行时库,如_tzset文档所示 。 这不是每个会话的设置,至少不是Windows使用单词“会话”的方式。

EDIT1

从文件时代 ,我读了以下 –

FindFirstFile从FAT文件系统中检索本地时间,并使用当前的时区和夏令时设置将其转换为UTC。

虽然我使用NTFS文件系统,但我相信它使用相同的机制,即从文件系统中检索本地时间,并使用当前设置将其转换为UTC。 这就是我注意到差异的原因。