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

问题描述

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

现在如果我检索 time_write _findnext（）为返回<$ c>元素 _finddata_t c> emp10.ibd 。我希望返回的时间戳应该接近

Epoch时间戳1477027260，如上图所示。

但我得到time_write为1477043509

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

我想了解为什么有4:30的时间差在GMT上面共享的两个图像？ 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使用会话一词。

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"."

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