none
FileCreationTime and System Time are different RRS feed

  • Question

  • Hello everyone,

    I have been working with the application and that deals with FileCreationTime of the received file and was facing problems. I happened to check the Tracked Message Events there I found the FileCreationTime is different for example,

    I dropped the file in the receive port a 10.58 am

    and FileCreationTime looks like,

    why is there a change, is it a normal behavior. I think this is the reason I am facing problem.Any help is really very appreciated. Struggling with this for the past 3 days.

    Thanks

    Monday, November 17, 2014 4:15 PM

Answers

  • Actually, it's not different, the two timestamps are equal but one is displayed in local time while the other is UTC.

    However, regardless of the display issue, I would strongly advise against using a file timestamp for any decision making.  The value can be set differently under any number of unpredictable circumstances.

    • Marked as answer by vdha Monday, November 17, 2014 5:25 PM
    Monday, November 17, 2014 5:04 PM
    Moderator

All replies

  • Can you check if your receive port is ruining on a timed window?

    Regards Pushpendra K Singh

    Monday, November 17, 2014 5:01 PM
  • Actually, it's not different, the two timestamps are equal but one is displayed in local time while the other is UTC.

    However, regardless of the display issue, I would strongly advise against using a file timestamp for any decision making.  The value can be set differently under any number of unpredictable circumstances.

    • Marked as answer by vdha Monday, November 17, 2014 5:25 PM
    Monday, November 17, 2014 5:04 PM
    Moderator
  • I am sorry, how do I check that. Thanks
    Monday, November 17, 2014 5:04 PM
  • Thanks Johns. My requirement is depending on time the file is received, process has to decide sending mails on different ports. Can you suggest me how can this be approached
    Monday, November 17, 2014 5:07 PM
  • Hi vdha,

     

    I belive this query is in realted to your another forum post: https://social.msdn.microsoft.com/Forums/en-US/ac9af715-6392-4272-8daa-f2ed7b0915e8/retriving-the-timestamp-of-the-received-message?forum=biztalkgeneral


    The context property File.FileCreationTime is the file creation time of the file. Not the time when it has been consumed. If you’re using folder locations to drop files, this changes. To see the exact time. Disable the receive location, drop the file in the folder (file will be not processed as the Receive location is disable). Check the properties of the file, you will see the file creation time.

     

    Then now enable the Receive Location, by enabling the tracking on the Receive  Port. Once he file has been processed you see the FileCreationTime in the context property of the message. This shall match the file creation time which you saw in the properties of the file.

     

    If you want to have logic based on the file arrival date or file consummation datetime in BizTalk have your logic based on MessageTracking.AdapterReceiveCompleteTime context

     


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Monday, November 17, 2014 5:21 PM
  • There shouldn't be any difference.  Consider:

    • The time hasn't changed, you just need to interpret it correctly.
    • The timestamp in the file is not guaranteed to be consistent.  There is no way to resolve this.  When copying a file whole combination of NTFS, the Shell, CIFS and who knows what else, will do it's best to preserve the timestamp, but may not.  If a system is writing directly to that location, then sure, it should be consistent.
    Monday, November 17, 2014 5:23 PM
    Moderator
  • So I have check the time using the UTC format for the FileCreationTime right
    Monday, November 17, 2014 5:27 PM
  • Ashwin,

    Thank you so much.

    As Johns said, the time formats are different. The current system time zone is USA EST and the FileCreationTime is in UTC format. I think that is the reason for issue I am facing.

    Monday, November 17, 2014 5:34 PM