WIN7 File modification date precedes file creation date?

Firstly it’s important to point out that this strange occurrence is NOT a Xojo issue.

My software allows users to import files from others systems etc. I’m using .CreationDate to get the date the file was created.

As a courtesy to the user, after selecting the file, they are presented with a dialog box (below) which shows the filename and file date/time which has been extracted using FolderItem. The user can edit the defaults if needed.

But now I realise there is an issue. It seems that WIN7 file system - or any other file system for all I know at this point, does not actually retain the “creation date” when copied from another source. Therefore we end up with a somewhat absurd, perplexing, ridiculous and unpalatable scenario where a file modification date can precede it’s creation date.

As such:

In the orange import dialog box above, the user is able to simply edit the date - which is fine, but they may not understand that, (or perhaps can’t read) and could leave it as the default and therefore create a chronological paradox. It’s also important to point out that editing the date does not change the file attributes, but is there only for a record for posterity…

An example:

So now I’m not sure how to proceed. The Date is very important because my software is used to record and analyze tests. The user needs to know when the tests were performed. This all works perfect if the tests are recorded using my software. The issue is only to do with “Importing” data.

Hope this all makes sense.

Your thoughts much appreciated.

When copying a file the copied file is actually a new copy that has been ‘just now created’.

On the other hand zipping the file and then extracting it after it has been copied doesn’t modify the creation date at least on windows. Using 7zip does alter the creation date when unzipping though.

EDIT: You could use robocopy.

Hello Neil,

I am not sure that there is a perfect solution for this. The reason why I say this is that a file can be created in Australia (time zones are ahead of North America) and emailed to Simone in North America which changes the edited time and date to one which is before the creation date.

One possibility is to default to GMT (Greenwich Median Time?) which would provide a more absolute date - and has its own warts and issues. :slight_smile:

Another possibility is to be able to record the time that the file has been edited, and I am not exactly sure how to do this in code at the moment.

I have a project where time is critical (milliseconds) and a computer is dedicated to keeping track of dates and time on that one computer. This removes the issues with time zones, bios batteries being completely discharged, and user error. Everything is synced to the one computer and uses only the one computers date and time clock.

This just provides a few helpful thoughts with context for discussion.

Are you using REAL/Xojo’s CopyFileTo method to copy the file? I would think that function should do all this for you - though it should treat the “copy” as a brand new file where all the attribute dates are equal. So actually we would hope CopyFileTo would do nothing aside from making a new file that has a new set of dates.

Remember there is no such thing really as a “copied file” like there’s some historical data saying “this file is based on this other file”. It’s almost like you read the file data into a buffer and wrote it back out, it’s all completely new. So I don’t know why you’d get the paradox you describe.

Of course MOVING a file is a different matter altogether, the attributes MUST be preserved.

A time critical system shouldn’t be relying on file time stamps, as you have found out, os’s differ as do timezones, what is updated when copy/move happens or when files are touched.

Is there no option to read the time out of the file or from the filename ie: 2017_01_24_10_56_18_GMT_test3 ?

Are there any logs that this other system dumps that you can parse to find when the file was written?

Just trying to think of alternatives as you say you can import from other systems which you might not have the ability to tweak. Could you put in a feature request to the author of the other app to add filename timestamps?

Or, if the modified date is older then the created date, then you know the file has been copied and you can read out of the modified date instead. You can do this because when you copy a file, the original files creation date becomes the new files modified date and the new files creation date is the copy date. (when I say date I mean date&time)

or just have your program write this data into the files its creating even if they are on other systems

and then you have to make sure you record enough info (like their current gmt offset on the other system + current time) to be abel to read it and convert that back into the right date & time

such fun

Thanks everyone - this discussion has been very useful.

Although I’ve always been aware of the creation and modification dates of a file, I had never really closely looked at it until now. I still don’t understand how, as per the file properties box example (below) that the modification date can precede the creation date:

From written notes, I know that the original file was created in Dec 2011. It was modified in June 2012, then copied via ethernet from an old computer in March 2017 to test with my new software. As far as I’m aware, if the file is “copied” then the Create and Mod dates would be the same.

Fortunately my software isn’t as critical as Eugene’s refered to project. I imagine that would very complicated.

My software is not very complicated. It records data off a load cell attached to the usb port, draws a graph and does some basic calculations. The user should at least be able to import files that were recorded on other systems.

There are no standards because most of this sort of testing is experimental using software and contraptions of who knows what. Nevertheless, I’ve decided that the type of file to be imported should be a basic vanilla text file *.txt (or *.csv perhaps later) where force values a shown for each line:

0 25 56 110 280 509 1019 etc...

It will be up to the user to convert from their old system.

In a rather ironic twist, a while back I decided my software will name files as per:

After a recording is done, regardless of the system date format, an incremental counter plus the date/time stamp is appended to the file name - therefore eliminating any possibility of chronological confusion - which is what I have witnessed and what this thread has been about.

So, I guess I can say if you use my software to record (unless you edit the filename), then it shouldn’t matter if you copy/duplicate/move/email etc. the original recording date and time will remain intact.

It’s almost as though I could see into the future

Anyway, I thought I could add the date automatically from an imported file, but obviously not. So I’ve decided to leave it up to the user to input the date and time manually otherwise it will default to “Date Unknown” which could be changed at a later date.