답변됨 FileDateTime to get UTC (GMT) back?

  • Sunday, April 29, 2012 9:58 PM
     
     

    Hi all.  I looked at some other posts, but nothing that was really what I am wanting to do.  I have an app that goes out and looks at some files for the Date & Time so that I can compare later for if a newer file is in a directory.  However I have seen that between some file copy's, I have files reporting back different time stamps, but in actually the files are the same, and I am assuming the time zone may be off of one of the computers that the file is copied from.

    How can I make this work correctly?  This is what I have, but it still returns the files with the hour off between them and the UTC is changing the time, but still get the hour difference. (Obviously i'm changing the strPattern to whichever directory I am looking at):

    strStamp = FileDateTime(strPattern).ToUniversalTime

    is there a different property on the file I should look for?  The files belong to a software program, so they are not your typical .txt files or anything.

    Thanks in advance!

    Mort

    Edit:

    I meant to add that I see some posts in other program languages, but not VB.  So any insight would be helpful.  I also stumbled upon File.GetLastWriteTime this morning doing some more searches, so I will do some tests today with it today to see if I get any different results.  I think my lack of understanding of which method or property to use is the issue here, I'm sure someone can point me in the correct direction.  Thanks!!

    • Edited by Mort81 Monday, April 30, 2012 12:26 PM Forgot to add
    •  

All Replies

  • Monday, April 30, 2012 1:42 PM
    Moderator
     
     

    Hi Mort,

    Welcome to the MSDN.

    OK, please try it, if you get further issues, please feel free to follow up this thread.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

  • Monday, April 30, 2012 1:58 PM
     
     

    Mort,

    The FileDateTime is returned as a DateTime structure from the file last modification date. It makes no sense to set that to UTC because a DateTime is a struct which uses as value the tick which is a long (int64) where in are the tics in 100th nanoseconds since 1-1-1 0:0:0.

    However you have to know what is written to the Modified DateTime in the file.

    You can probably better use the File Info and then in that the LastWriteTimeUTC

    http://msdn.microsoft.com/en-us/library/system.io.filesysteminfo.lastwritetimeutc.aspx

    Sample on this page

    http://msdn.microsoft.com/en-us/library/system.io.filesysteminfo.aspx


    Success
    Cor

  • Monday, April 30, 2012 3:41 PM
     
     

    Hi and thanks for the responses.

    My reasoning for trying to use the UTC was in thinking that the time zones were off between machines.  So I thought the UTC would compensate and return the files the same time (if the files were identical that is), regardless of time zone.  However in testing today, I think that perhaps the time zones were in fact the same, but maybe one machine's time was just off an hour.  I don't have access to the original machines, just the files themselves so I can't be entirely sure here and obviously the files aren't going to tell me what time zone the machine that wrote to them are.  I think that I may look at if the files are exactly an hour apart, and the length of the file is the same, then I can assume the file is the same in both directories.  Seems a bit risky, but I can't see the file staying the exact same size, hour:min: second exactly the same except for a hour difference.  (I would hate to think of the odds of that would be)

    However with that said.  I would like to clear up a question I still have on the matter.  If in fact that this was a time zone issue, is the strStamp = FileDateTime(strPattern).ToUniversalTime ok or is filesysteminfo the proper way to handle this?  Meaning which way would catch and return the files are the same correctly if this was a time zone issue only?

    Thanks!

    Mort


    • Edited by Mort81 Monday, April 30, 2012 3:43 PM finish my thought
    •  
  • Monday, April 30, 2012 4:07 PM
     
     

    Just a comment.

    What is the cost to the business of incorrectly identifying a file as unchanged when it has been changed? You need to take that into account as well as the probability of a changed file having the same size and an hour difference in time. E.g if you put the probability at 0.0001 and cost at £10million the risk is £1000; if the probability were 0.1 and cost £1 the risk is $0.10 (i.e. 10p). Then ask, can the business bear the risk? You also need to consider cost of identifying a change when one has not happened (though I suspect that is negligible).

    This article explains file time - but I suspect you have already seen it.


    Regards David R
    ---------------------------------------------------------------
    The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones.
    Object-oriented programming offers a sustainable way to write spaghetti code. - Paul Graham.
    Every program eventually becomes rococo, and then rubble. - Alan Perlis
    The only valid measurement of code quality: WTFs/minute.

  • Monday, April 30, 2012 4:20 PM
     
     

    David,

    For that we use here the sentence Penny wise, Pound Foolish. 

    :-)


    Success
    Cor

  • Monday, April 30, 2012 4:23 PM
     
     

    Mort,

    I think that the VB FileDateTime is just a wrapper around the System.FileInfo that is done with many functions from VB, sometimes they are a little bit more advanced. However, I'm not sure about that. But in your case I would have tried it also with the System.FileInfo. You have those files. Not me.


    Success
    Cor

  • Monday, April 30, 2012 4:30 PM
     
     

    Cor

    Also take into account "Look after the pennies and the pounds will take care of themselves."

    Don't you just love proverbs. LOL.


    Regards David R
    ---------------------------------------------------------------
    The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones.
    Object-oriented programming offers a sustainable way to write spaghetti code. - Paul Graham.
    Every program eventually becomes rococo, and then rubble. - Alan Perlis
    The only valid measurement of code quality: WTFs/minute.

  • Monday, April 30, 2012 5:33 PM
     
     

    David,

    My wife tells me all the time that I need to "talk out loud" and don't assume that people know what you are saying all the time.  Case and point here of my app.  This app is not a "production" app, its just for me and my toolbox to check some files of a software package that is specific.  I agree with you and would never attempt what I proposed on a "production" app (not that I build for production, I leave that to the pros).  My line of work is human machine interfacing for control systems (ISA95), so 99.9% of the time these apps that I create are just to help me develop screens and etc.  The other .1% would be for someone else in my same shoes.  But for sure not to use on the end results.  Most software I use has usaually a Basic or VBA background so between google and self teaching I can usually peice togeather a tool or two to help myself.  Someday perhaps I'll get into a class or two on the powers of vb.net.  However with that said, you did re-ground me a bit and I think instead of filtering out the time stamps "I think" match first, i will go ahead and show the results and have an option to filter later so that way I have to see them first and then can decide if I need them or not.

    Cor,

    Thanks for the help.  I was playing with the FileInfo today and did not know that it was one and the same.  I think I will continue with what I had, and add the filter I spoke of for after the results are displayed.

    Thanks everyone for the help and the candid responses!

    Mort

  • Monday, April 30, 2012 5:50 PM
     
     Answered
     Instead of relying on their timestamps and file sizes which isn't very reliable, you can compute the hash (MD5, SHA-1 or SHA-2) of the files and compare them.
    • Edited by Stanav Monday, April 30, 2012 5:51 PM
    • Marked As Answer by Mort81 Monday, April 30, 2012 8:27 PM
    •  
  • Monday, April 30, 2012 8:29 PM
     
     Answered

    Stanav,

    Well, it will take me a bit it read and understand about the MD5 and what is really going on under the hood, but after some testing, this does seem to work for what I am doing.  Thanks for the insight.

    Here is where I found a couple functions that past back the hash string for my compare.

    http://www.nonhostile.com/howto-calculate-md5-hash-file-vb-net.asp

    Mort