Caveats

Warning
Do not use WRECK on your company's or any mission critical documents.
I shall not be held responsible for any damage done.

This tool may not work 100% accurate all the time; there are certain situations when it may not be accurate in obtaining the correct original timestamps from some files. So it is advisable to understand its limitations and how it handles missing metadata before applying to your personal files.

In any case, it is highly recommended to backup the file time attributes prior to any modifications by WRECK. At the minimum, it gives you a chance to recover back to the state before any time stamps are overwritten and lost should you ever need it.

Note that once the creation timestamp is lost in the past, the loss is permanent -- it is impossible to recover the original high-precision timestamps from any backups with incorrect timestamps.

Metadata

WRECK makes an attempt to recover and restore the supposedly "right" or "correct" creation timestamps using any embedded metadata recorded by the writing or encoding software when it created a file, or use a series of rules or heuristics to attempt to guess an estimated date closer to the actual one over the inaccurate one recorded in the file system. This is done on a best-effort basis and it uses inferences based on certain assumptions.

WRECK tries to use any embedded metadata generated by its authoring or producer software as the the default primary source of timestamps, assuming they are a reliable source of timestamps.

There are times when these methods fail to provide useful timestamps. For example,

1. Lack of metadata support: The file format does not support timestamp or date time related metadata. E.g. text files.
2. Unrecognized date time string format: WRECK recognizes a few commonly encountered formats in test data, but given the infinite number of unstandardized ways to encode a date time string by user and different software applications, rarer formats may not be recognized and are erroneously overlooked.
3. Wrong values: The metadata timestamps are filled with fictitious, made-up, placeholder values by the user or authoring software that are obviously out-of-range. E.g. files tagged as created before the 1980s or 1970s before computers became common, or somewhere far into the future, or simply empty string or all zeros e.g. 0000-00-00T00:00:00.000 which cannot be true or parsed.
4. Wrong date time: The computer had an inaccurate clock recording the wrong timestamps at the time due to a bad operating system clock that was out-of-sync, or the user had a history or habit of manipulating his system clock by setting the time manually. The generating software would use any time reported by the operating system or the system clock at the time of writing the file.

Inferences

In the absence of useful accurate metadata values from the file, WRECK would turn to various methods of inferring the possibly correct timestamps. Users should be aware of how these inferences are made, their underlying assumptions and whether they are valid for their situation.

Inferences are made based on different file formats, path or file names, existing file system timestamp attributes on a best-effort basis, if a reasonable timestamp can be obtained. The following inferences are made:

1. For path/file name: if the file name or path name contains a portion that resembles a valid 8 digit date string and/or 6 digit time string that is parsable e.g. 20141023 or 20141023_234935, .

   For string that contains only a date portion, the default time of the day is 12 PM local time. This is useful if the user files and folders have a naming convention that include a user-specified date time, or for digital camera JPEGs that have date time in their names e.g. IMG_YYYYMMDD_HHMMSS.jpg.

   The number string is ignored if it fails to parse into a reasonable date time between Jan 1, 1980 midnight and time of execution.

2. For ZIP/7-Zip/RAR/ISO/TAR archives: Similarly to normal folders/directrories, the archive entries for each file contained within have a last modified time stamp that is used to determine the creation and modified time for the archive. It is assumed that the archive was created and modified only after the last file inside it has been created/modified.

3. For directories: the earliest and latest time stamps are derived from the children/descendent files contained within.

4. For files: the existing file attribute timestamps from the file system are used to obtain the earliest and latest time. This is used for files without metadata values.

In general, the earliest time is used for the folder/file's creation time, and the latest time for the last modified and last accessed time.

Inferred timestamps can never be accurate; it is an estimated approximation of a date time that is perceived or assumed to be closer to reality, than the current one already recorded by the operating system and file system when they lost the original creation or last modified time.

User-Specified Custom Limit

As a last resort, and potentially useful method for artificially limiting the latest timestamp, the user can specify a upper limit for the maximum date time. Any timestamp found in the metadata or file system attributes that is past the user-set limit would be capped and restricted.

This option is useful if the user is certain that a set of files and sub-folders under a particular folder are guaranteed logically to be created or modified on or before a hard limit.

WRECK would respect the user limit religiously once set, and override any metadata values or file system attributes found naturally within the file or from the file system that exceeds this imposed limit. The onus is on the user not to specify an inaccurate limit if used.

Related to the user-set upper limit, there is a lower limit for date timestamp set at Jan 1, 1980, midnight. This is set within WRECK and cannot be overridden by the user at runtime. In theory, this assumes that any file timestamp earlier than Jan 1, 1980 are either invalid or fictitious.

The assumption is that under normal circumstances, we should not encounter valid digital files created before the MS-DOS/PC-DOS era if we are dealing with files on personal computers.

This hard limit can only be changed by modifying the source codes.

If these caveats do not apply to you in general, then WRECK may work well enough for you.