CreationDate being set to several seconds in the past

  • 1
  • Problem
  • Updated 6 months ago
When uploading a file in the UI sometimes the CreationDate is being set to several seconds in the past. This recently started occurring( or maybe its just rearing its head more often now). Couldn't find any open issues regarding this but its impacting several mutual customers since we rely on this CreationDate to be accurate when polling for file and folder changes. If you guys are already working on this is there a timeline for the fix yet? Thanks!
Photo of Taylor Clark

Taylor Clark

  • 6 Posts
  • 1 Reply Like
  • confident in ShareFile support

Posted 6 months ago

  • 1
Photo of Andy Berryman

Andy Berryman, Employee

  • 14 Posts
  • 5 Reply Likes
There's always a chance for there to be a "drift" between what your server indicates as the current time and what our servers view it as.  Can you give me some more information on this "polling" process that you refer to that is looking for changes?  That way we can see if we can find a workable solution for you.
Photo of Taylor Clark

Taylor Clark

  • 6 Posts
  • 1 Reply Like
Hi Andy, 
Thanks for the response. In all of the integrations we've built we've rarely seen server times off by more than a few hundred milliseconds so it does appear to be a system time issue with your servers. I recorded a short video where I ran some tests to demonstrate the discrepancy in the timestamps. You can view it here - https://cl.ly/3v1r2r3m283b The results are pretty consistent, SF is setting the timestamp to ~56-57 seconds in the past or roughly 1 minute in the past. What we do is poll all of the folders in our ShareFile account on an interval. For example we'll poll once a minute to see if any folders or files have been created or updated. We compare the timestamps to see if they are between our current poll time and our last poll time. What is happening with the recent changes to the timestamps is our system is unable to detect file changes made 1 minute after the last polling time since the timestamp is being set to 1 minute in the past. We were happy to see webhooks added recently as they resolved this issue for us but unfortunately they do not detect new folder events which is a requirement for a few of our customers. We're hopeful the ShareFile team can correct the timestamp so that this will go back to functioning as it has in the past. 
We appreciate the help. 

Cheers,
Taylor 

Photo of Taylor Clark

Taylor Clark

  • 6 Posts
  • 1 Reply Like
Hi Andy, just to clarify my last comment about webhooks resolving the issue - they resolved the issue of us having to use polling not the current issue with timestamps. Also, we've been using this polling method for > 1 year without any issues other than this issue which was resolved - https://community.sharefilesupport.com/citrixsharefile/topics/incorrect-created-date-on-files-folder...
Photo of Andy Berryman

Andy Berryman, Employee

  • 14 Posts
  • 5 Reply Likes
Can I assume that your "Sharefile timestamp" value in the data above is coming from the "CreationDate" field in the response?

As for the "drift" ... I'll check with our Operations team to see what our servers are detecting the current time as.  I can see from your video that your local timestamp appears to be "on time".  Its possible that our server clocks are running behind and that could account for the difference that you are seeing here.

However ... As this issue demonstrates ... The pattern that you have built here is a fragile one and has a major assumption on your clock and our clocks being in sync ... Which is virtually impossible to be accurate.  The process has been working because you have been using a buffer of 1 minute and the "drift" has been less than that.  If you changed your buffer to 2 minutes then things would go back to working as you have been for a while now ... Until the "drift" reached close to 2 minutes ... And then it would "break" again.

With that said ... I agree that a "drift" of almost a minute is rather extreme and we will definitely look into correcting this if that's the case with our servers.

If I may offer a new proposed pattern ... Rather than checking to see if the returned timestamp value is within your local clock's value last minute (your poll interval) ... How about after each poll you remember the latest returned "CreationDate" value in that poll ... And then in the next poll use that value as your "changed since" value.  If you use this pattern then you will be using our clock values for the real logic and the "drift" shouldn't matter because it would at least be consistent.  Your clock would only be used as a way to just execute your process.

I realize this would mean that you have to make a change and I'm not in any way dictating that you have to ... But I believe that your process would be much less fragile.

I'll also check to see if I can get an ETA for you on the delivery of webhook events for new folders as it sounds like it would eliminate this entire process for you in general.

-Andy
Photo of Andy Berryman

Andy Berryman, Employee

  • 14 Posts
  • 5 Reply Likes
UPDATE:
  1. I can confirm that our servers are currently "behind" by roughly 57 seconds and we are working to get this corrected.  I don't have an exact ETA but I'm hoping that by the end of the day that it will be resolved.
  2. We already have a backlog entry created for exposing the Create Folder event via Webhooks ... Its in the grooming phase right now.  So I cant give you a release date but I can definitely tell you that it is in the works.
-Andy
Photo of Taylor Clark

Taylor Clark

  • 6 Posts
  • 1 Reply Like
Thanks Andy! Greatly appreciate your help
Photo of Taylor Clark

Taylor Clark

  • 6 Posts
  • 1 Reply Like
Also, great to hear about the plans to add new folder events to webhooks. 
Photo of Taylor Clark

Taylor Clark

  • 6 Posts
  • 1 Reply Like
Hi Andy, 
Any update on this?