Fix default custom DateTime value bug #228
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Java
new Date()
defaults to current time of object instantiation, which would not trip the special cases by default.C#.NET
new DateTime()
defaults to a hard coded 01-01-0001 00:00:00.000 which causes the extracted metadata value to be overwritten.This causes confusion in the date time value selection in TimestampReducer that picks the wrong default file system value because the supposed user-defined custom date time is earlier than even the application-defined lower limit of 01-01-1980.
This is further overwritten by a placeholder value introduced during development which defaults to the current file system file time (creation, last modified, last accessed).
In summary, the bug was a series of wrong values replacing each other:
TimeUtils.VALID_PERIOD_MIN
limit of 01-01-1980 allowed by Windows ExplorerThe placeholder value was introduced to allow the application to run but was forgotten.