-2

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 -

Local time to epoch conversion

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 epoch to local time

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.

Community
  • 1
  • 1
irsis
  • 952
  • 1
  • 13
  • 33
  • I'm... not sure what the question is. The documentation says the times are stored as UTC. Are you comparing against observed results from some code? If so, please post that code. – andlabs Oct 21 '16 at 03:41
  • It's UTC as documented. – David Heffernan Oct 21 '16 at 03:53
  • 4
    "Local time in UTC" is a self-contradictory phrase. Please clarify. – Harry Johnston Oct 21 '16 at 04:04
  • @andlabs hope question makes sense after I provided the example. – irsis Oct 21 '16 at 06:00
  • Did you read the **"No support for other timezones"** (other than GMT)? Why did you enter "IST" ? – MSalters Oct 21 '16 at 10:06
  • @MSalters Well if you read the post, All I am trying to do is to get an EPOCH timestamp from the human readable modified date according to system time zone. I see epoch timestamp is generated correctly. Later when I get _finddata_t structure will file detail then I should get a timestamp close to the one generated previously. – irsis Oct 21 '16 at 10:11
  • What part of "this time is stored in UTC format" are you finding hard to understand? – David Heffernan Oct 21 '16 at 13:24
  • It seems like you are confused as to what "epoch" means. "Epoch" is not itself a time system, nor is it a time zone; instead, it's a moment of time that is used to define time representations. The Unix timestamp epoch is 1970-01-01 00:00:00 +0000 UTC. The Windows `FILETIME` epoch is 1601-01-01 00:00:00 +0000 UTC. Epochs are only useful if you need to convert between representations of time values. Time zone conversion is different. "UTC" and "local time" refer to time zones, not epochs or time representations. – andlabs Oct 21 '16 at 17:15
  • Does your computer know what time zone it is in? Is the file on an NTFS volume or a FAT volume? – Harry Johnston Oct 22 '16 at 01:54
  • @HarryJohnston It is NTFS volume. Yes, the current time zone set on my computer is IST as I mentioned in the question. – irsis Oct 22 '16 at 02:20
  • @andlabs I completely understand the epoch and UTC meaning all I am trying to put forward is that outcome of _finddata_t structure is not my machine time zone independent i.e. UTC time. There seems to be caveat in the documentation. – irsis Oct 22 '16 at 02:22
  • Why don't you start from the assumption that the docs are correct and your understanding is wrong, and then try to find out what is wrong with your understanding? – David Heffernan Oct 22 '16 at 06:55
  • @DavidHeffernan I agree that is true 99.99% of the time and a programmer must operate on that premise. See the interesting observation in the answer after my 48 hrs of troubleshooting. – irsis Oct 22 '16 at 08:52
  • *"there is a file `emp10.ibd` for which windows shows [...]"* - Windows is an OS. It doesn't show time stamps. It allows programs to run that can. What program are you using to display the file write time? – IInspectable Oct 22 '16 at 15:58
  • @IInspectable Did I say Windows show timestamp? Isn't both Date Created and Date modified mentioned as human readable which you get when you see the property of the file. – irsis Oct 23 '16 at 13:11
  • Yes, you did. And that doesn't make much sense (frankly, like most of your question). I could repeat myself, and try to explain, that we need to know, which **program** you are using to display the timestamp. Your lack of coöperation demonstrated in the past doesn't instate much hope, that you are even capable of comprehending, why this question is a poor question, and what you need to do to improve it. – IInspectable Oct 23 '16 at 13:30
  • @IInspectable Thank you very much for feedback. I must admit my comprehension skills are poor so it is very difficult for others to follow the question. In reality question had evolved too as more and more clarity I got during troubleshooting. Yet, I am happy that I am able to reach to the root cause of problem with the help of SO and you guys. – irsis Oct 23 '16 at 14:05

2 Answers2

1

Local time is UTC plus a geographical offset plus potentially a seasonal offset. A UTC timestamp has no such offsets.

In this particular case, the exact format is seconds since1970-01-01T00:00:00Z i.e. January 1st, 1970, at midnight UTC.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • Could you please elaborate how format is coming into picture in this particular case ? – irsis Oct 21 '16 at 07:20
  • @Rahul: Read my last sentence again. There is nothing to elaobrate on, really. – MSalters Oct 21 '16 at 09:51
  • AFAIU, except leap seconds adjustments there is nothing additional in the UTC time stamp when compared to EPOCH time stamp. I can expect a few seconds time difference by using epoch converter but not 4:30 hrs. – irsis Oct 21 '16 at 10:02
  • @Rahul: There's of course the possibility that the time of the computer was incorrectly set when the files were created. I've got no idea what you mean by " EPOCH time stamp". – MSalters Oct 21 '16 at 10:05
  • time of the computer is set in IST. well epoch and utc timestamps are not same. utc timestamp includes the leapseconds adjustments while epoch timestamp doesn't. But all that doesn't matter for question posted. I am asking about _finddata_t structure filled by _findnext() API – irsis Oct 21 '16 at 10:43
0

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.

irsis
  • 952
  • 1
  • 13
  • 33
  • I updated the post so that it might help others in future. I don't bother for downvotes as long it might help others but please care to explain the reason. Isn't is valid finding ? What's wrong with it ? – irsis Oct 22 '16 at 09:02
  • Neither the question nor this answer are useful. Both are just an overly verbose way to say: Changing the timezone has an effect on the timezone. Great find! – IInspectable Oct 22 '16 at 16:02
  • @IInspectable: I disagree. I wasn't aware that the C runtime has its own timezone setting, distinct from the timezone set in Windows and set based on an environment variable - if I had been, I'd have guessed that this was the cause yesterday, as soon as the OP edited the question to include a proper problem statement. (And nobody else guessed either, so I'm thinking it's not just me!) – Harry Johnston Oct 22 '16 at 21:42
  • 1
    Rahul, 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](https://msdn.microsoft.com/en-us/library/90s5c885.aspx). It isn't a per-session setting, at least not in the way Windows uses the word "session". – Harry Johnston Oct 22 '16 at 21:47
  • @IInspectable: besides, now that I think about it further, _finddata_t is supposed to return the timestamp in UTC. Assuming for the moment that the OPs observations are correct (I haven't attempted to reproduce them) it shouldn't matter that the C timezone is different to the system timezone, the runtime should still return the correct UTC timestamp. If it doesn't, that sounds like a bug - or am I overlooking something? – Harry Johnston Oct 22 '16 at 21:53
  • @HarryJohnston Indeed, that could be the reason my point is that behavior would be same for _finddata_t struct as well but it is not documented and FILETIME struct is offcourse not affected by _tzset. +1 for it. – irsis Oct 23 '16 at 12:55
  • @IInspectable It may not look great find to you but I am sure HarryJohnston has valid point. I hope you agree. – irsis Oct 23 '16 at 12:58
  • 2
    @HarryJohnston: I'd like to disagree here. The OP never made an attempt to show the code they are using, nor did they ever respond to inquiries to name the programs they use to display file meta data. The fact that no one guessed at the purported root cause is two-fold: `1` The question is so fuzzy, that it's hard to make anything of it. `2` No one in their right mind would use the CRT-provided [filename search functions](https://msdn.microsoft.com/en-us/library/kda16keh.aspx). They are the least portable option, and don't provide **any** inherent benefit. – IInspectable Oct 23 '16 at 14:55
  • @IInspectable Well, I would like to disagree here as well. I had provided all information I was asked for. I suppose I tried to elaborate the problem to the best of my abilities. There is nothing special in the program which just iterate over a directory using _filefirst() and _findnext() and make note of the meta information of each sub-dir and file inside. In fact that would make post unnecessarily verbose. Sure, I respect your view point though. Lets move on. – irsis Oct 23 '16 at 15:12
  • You never provided the code **you** implemented, to read/display/analyze the time stamp. And you never explained, which other program you used to display those time stamps. You left out **all** the significant information required to turn this into an answerable question. – IInspectable Oct 23 '16 at 15:17