Updated JabRef deletes 'timestamp' fields from the database

[sauliusg]

JabRef version 5.3 and 100.0.0 (commit 0dd4de7) on Linuxmint-20.1 and LinuxMint-19.3.

• [x ] Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

Since the version 5.3 (and in the current 'master' tip) the 'timestamp' field is silently deleted from my BibTeX database, even it was present there, and the "timestamp" column is configured to be show! Moreover, all options that allowed me to configure the time stamp and its format are gone, so I can not restore the previous behaviour which I rely upon.

Steps to reproduce the behavior:

1. Start JabRef 5.3 from the command line (linux portable archive), or './gradlew run' in the cloned git repository dir;
2. load a database created with previous JabRef (3.x-4.x-5.[012]);
3. The display of the Timestamp column (which I configured for 5.2, and it worked!) is empty; when the file is saved, the 'timestamp' fields are removed without warning (and without asking), and replaced by 'creationdate' with incompatible format.
4. Trying to configure the timestamp back does not work:
   
5. The 'creationdate' field in the output database is created even though both checkboxes "Add timestamps ..." are not checked, contrary to what was expected.

While I suspect this was designed in as a feature (and possibly discussed a lot...), I regard the behaviour as a bug, and a very nasty one (a serious usability issue!):

• it modifies existing BibTeX databases in an incompatible way, without asking, and with no means to retain compatibility – thus it breaks downstream tools that process that database;
• it insists in momentarily switching to a new BibTeX file layout, thus breaking compatibility with tools that generate these bibtex files;
• Not all people switch JabRef versions simultaneously; thus, there is a pressing need to collaborate on the same databases (shared e.g. via the Subversion repository), using various version of JabRef.

The suggestion would be to put back the 'timestamp' with its old functionality and old configuration capabilities; the new 'creation/modification' date fields can be added additionaly if activated. It should be fully under the user's control to select which fields have to be added to the database. Upon activation of creationdate field, a user can be asked if he/she wants to copy old timestamps to the new field, but this should be optional and the old fields should be retained by default.

[calixtus]

refs #7334 #7351

[sauliusg]

refs #7334 #7351

Fully agree with ilippert in #7351. The migration strategy is suggested above. Can it be implemented? (i.e. agreed in principle; who and when will implement it is another question ;) ).

[ilippert]

I guess it suffices to keep one of both issues open, this or #7351

[koppor]

Duplicate of #7351. We identified the issue. Thank you for reporting.