Year sorting does not work for crossref entries

[ilippert]

JabRef 4.0.0-beta
Linux 4.10.12-200.fc25.x86_64 amd64
Java 1.8.0_131

In the entry table, sorting by year does not work, whilst sorting by timestamp works.
The log tells me:

Unable to parse stored date for field 'timestamp' with current settings. Clear button in calender popup will 
Unable to parse stored date for field 'date' with current settings. Clear button in calender popup will not work.

Also, the timestamp is not updated anymore (whilst it was updated with earlier versions of jabref).

I wonder whether some larger issue with dates exists - given #2806

[Siedlerchr]

Hi,
I can not reproduce this issue in the latest snapshot. The issue #2806 is only related due to the rework of the entry editor.

Thank you for reporting this issue. We think, that is already fixed in our development version and consequently the change will be included in the next release.

We would like to ask you to use a development build from https://builds.jabref.org/master and report back if it works for you.
Please try again with the latest version from here:
http://builds.jabref.org/master/

[AEgit]

Similar to @Siedlerchr I cannot confirm this issue with:
JabRef 4.0.0-dev--snapshot--2017-04-24--master--4e25cc642
Windows 10 10.0 amd64
Java 1.8.0_131

[ilippert]

Have updated to

JabRef 4.0.0-dev--snapshot--2017-04-29--master--749d774a0
Linux 4.10.12-200.fc25.x86_64 amd64
Java 1.8.0_131

and revisited the issue of sorting by date. I now recognise the following more specific segment that faces the date sorting issue: the non sorted entries are entities that do not possess own year fields but only crossref.

this also explains why sorting by timestamp works (as entries with timestamp have them from their own entries, rather than from crossref)

[tobiasdiez]

This should be fixed in the latest development version. Could you please check the build from https://builds.jabref.org/maintable-beta/. Thanks! Note this version is in a very early beta stage and might not work as expected. See #3621 for further details.