_finddata_t结构是否将time_write作为系统时间返回或受会话时区的影响？ [英] Does _finddata_t structure return time_write as system time or it is influenced by session timezone?

问题描述

我指的是 _filefirst（）和 _findnext（） API

现在如果我检索到 time_write _finddata_t 结构，该结构已由 _findnext（）为相同的文件返回，即 emp10.ibd 。我预计返回的时间戳应该接近

Epoch时间戳1477027260如上图所示。

但是我得到time_write为1477043509

如果我再次使用时代转换器我得到以下

我正在想明白为什么会有4:30的时差在格林尼治标准时间共享上述两个图IMO时间戳应该几乎相同。我在这里失踪了多少？

Edit2
对于那些正在要求示例代码的人而言。这里我粘贴另一篇文章的链接一年前我曾经问过同样的理由，但情况有所不同，我指的是_stati64结构。当时我没有进一步解决问题。现在很清楚，
_finddata_t和_stati64 API受到 _tzset的影响

解决方案

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

在这一点上，我开始调查我们通过perl脚本执行我们的程序的方式。我发现perl脚本将时区设置为 GMT-1 。

由于我的电脑在时区 GMT + 5： 30 ，所以我以前得到的结果是 +04：30小时的差异，原始帖子中提到。

因此，我想总结一下我的经验 - _finddata_t strcut 的结果受会话中设置的时区的影响，但 FILETIME struct 不受会话中设置的时区的影响，而是根据系统时区的时间。因为我使用 FILETIME struct 检索一次，另外使用导致问题的 _finddata_t strcut 。让我〜48小时找出这个有趣的观察。

为什么会发生这种情况？也许Harry在评论部分提供了答案。我在这里粘贴一样 -

更改Perl中的时区是可能导致TZ环境变量被设置，这将影响C运行时库，如 _tzset的文档。它不是每个会话的设置，至少不是Windows使用会话一词。

Edit1

从文件时间，我阅读了以下内容 -

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

I am referring the documentation of _filefirst() and _findnext() APIs here

These APIs return file information in a _finddata_t structure. I need to access file modification time from time_write element. Though documentation says that time is stored in UTC format (It is a times stamp). Documentation doesn't clarify if this time represents local time or UTC time. It seems to me that time_write doesn't return the UTC time instead its value is influenced by the system time zone settings.

My Question is - Does time_write returns local time represented in the UTC timestamps ?

Edit1 Here I explain what actually I am trying to understand. My system is in IST timezone. Now, there is a file emp10.ibd for which windows shows

Date Created - 10/21/2016 10:51 AM

Date Modified -10/21/2016 10:51 AM

I used epoch converter to find out the the epoch timestamp for which it turn out to be as following -

Now if I retrieve the time_write element from _finddata_t structure which has been returned by _findnext() for the same file i.e. emp10.ibd. I expect the returned timestamp should be close to

Epoch timestamp 1477027260 as shown in the image above.

But I get the time_write as 1477043509

If I again use epoch converter I get the following

I am trying to understand why there is 4:30 Hours of time difference in GMT in both images shared above? IMO timestamp should have been almost same. What obvious I am missing here ?

Edit2 For those folks who were asking for sample code. Here I paste link of another post which I had asked a year ago for the same reason but scenario was little different, There I was referring to _stati64 struct. I didn't troubleshoot the problem further at that time. By now it is pretty clear that _finddata_t and _stati64 APIs are affected by _tzset environment variable as Harry mentioned in this post while FILETIME struct is not.

解决方案

To troubleshoot further, next I used GetFileTime API to retrieve the the file modification time in FILETIME struct and converted the time into UTC timestamp. I got the time according the time set on my computer. I was expecting the same.

At this point I started investigating the way we execute our program through a perl script. I found that perl script was setting the timezone to GMT-1.
Since my computer was in timezone GMT+5:30, therefore I used to get resultant +04:30 hrs of difference as mentioned in the original post.

Therefore I would like to sum up my experience as - the outcome of _finddata_t strcut is affected by the timezone set in the session but the outcome of FILETIME struct is not affected by the time zone set in the session, instead it is the time according the system timezone. Since I was retrieving one time using FILETIME struct and another using _finddata_t strcut that was causing the problem. Took me ~48Hrs to find out this interesting observation.

Why does that happen? Perhaps the answer is provided by Harry in the comment section.I am pasting the same here as it is -

changing the timezone in Perl is probably causing the TZ environment variable to be set, which affects the C runtime library as per the documentation for _tzset. It isn't a per-session setting, at least not in the way Windows uses the word "session"."

Edit1

From File Times, I read the following -

FindFirstFile retrieves the local time from the FAT file system and converts it to UTC by using the current settings for the time zone and daylight saving time.

Though I was using the NTFS file system but I believe it uses the same mechanism i.e. retrieve the local time from file system and converts it to UTC by using current settings. That's the reason I noticed the difference.

这篇关于_finddata_t结构是否将time_write作为系统时间返回或受会话时区的影响？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！