Some enhancements and cleanups related to dates

[oscargus]

Based on the discussion in another PR (primarily @Siedlerchr as I recall) the date selector now returns the date in ISO format when applicable. Basically, it returns in ISO format for all BibLatex fields related to dates, while e.g. timestamp is still based on the preferences (there is a property FieldProperties.ISO_DATE which can be set to enable ISO format).

I also replaced some of the SimpelDateFormat usage with the new thread safe API.

Question: should we still support a user defined date format?

[koppor]

I currently have no clear picture about private fields. This is the context of #574 😄

[simonharrer]

Where is the configurable date format usable?

[oscargus]

Right now it is used in the timestamp field as far as I know. I guess that people may have their own format and then if we remove it, there will be a bit of hassle...

[tobiasdiez]

Since we want to get away from using Globals.prefs in logic classes, I would propose to add constructors which takes the format as input. E.g.

EasyDateFormat(String dateFormat)
   this(DateTimeFormatter.ofPattern(dateFormat))

EasyDateFormat(DateTimeFormatter dateFormat)
   this.dateFormat = dateFormat;

static EasyDateFormat fromPreferences(JabRefPreferences preferences)
    return new EasyDateFormat(preferences.get(JabRefPreferences.TIME_STAMP_FORMAT));

static EasyDateFormat IsoDateFormat = new EasyDateFormat(DateTimeFormatter.ISO_LOCAL_DATE)

[oscargus]

Good idea! I changed it.

[Siedlerchr]

In general, JabRef should only focus on the bibtex/biblatex specification for the standard fields.
Only user defined fields should accept a different style.

[oscargus]

So what about `timestamp`? Historically there's been support to generate your own format (and call it anything). Most likely people are not using ISO format since that has only recently been the default. I think the conclusion really is that we cannot drop the support for arbitrary date format since we once introduced it. I think the major issue really is that we need to propagate the format, although not that far and one can extract some class `TimeStampPreferences` to encapsulate it.

[koppor]

@oscargus The time discussion refs JabRef#130. Maybe, we should migrate away from timestamp to date-added and date-modified and use the format already provided by some other software.

[Siedlerchr]

I like the idea of having those two fields instead of the timestamp. We
should only make clear, that these fields are non standard biblatex/bibtex
fields.
As far as I found out, at least BibDesk uses them, from what I read maybe
Citavi or Mendely, too.

2016-07-20 19:18 GMT+02:00 Oliver Kopp [email protected]:

@oscargus https://github.com/oscargus The time discussion refs
koppor#130 JabRef#130. Maybe, we
should migrate away from timestamp to date-added and date-modified and
use the format already provided by some other software.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1575 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AATi5JgJtRf67CEiMMSVicRbsm1aCMi3ks5qXliAgaJpZM4JKNkH
.

[oscargus]

Fine with me. I guess we should provide a migration functionality before dropping the configurable format and field name support.

[oscargus]

I've rebased. Anything else at the moment?

[simonharrer]

Could you sum up what has been done here, and the associated pros and cons? Especially regarding a CHANGELOG entry, this is required anyway.

[oscargus]

At the moment it is primarily replacing `SimpleDateFormat` (for good reasons) in a number of places and making sure that the BibLatex fields related to dates get their result from the DatePicker in the correct format (yyyy-MM-dd as specified by BibLatex). A ChangeLog entry might describe the latter as a bug fix, if anything. The discussion is really about if we should keep the field usually called `timestamp` and if we should allow the user to specify the format of this field.

[oscargus]

And: JabRef preferences are injected in a few places plus replacing an array with a List in ZipFileChooser.

[simonharrer]

What I think would be cool:

1. Create two new fields (date-added, date-modified) which use default ISO-based time stamps which cannot be configured by the user. The user can only say that he wants these fields or not.
2. Create a migration from timestamp to the new fields.
3. Reuse the existing preference setting for the new fields. We should still use one setting to enable both fields and should not make it too fine granular.

[oscargus]

I agree that those two fields are better. Won't happen in this PR though as it is a quite big job. See JabRef#130 as well.

Anything else in this PR? See it as primarily making the format of the date field independent of the preferences (which it should be) and that we got rid of some of the SimpleDateFormat uses (see #1154, second checkbox almost clickable...).

[simonharrer]

Then this is good to be merged.

[oscargus]

Anyone has a good idea why the tests are failing? Locally they pass and Cookie is not even executed when running the test...

[Siedlerchr]

The problem is our custom Cookie handler which seems to be implicitly called by the HTTPUrlConnection.getResponseCode, considering the stacktrace:
And I guess it comes from the User Agent and is some Travis related stuff. Maybe travis uses some kind of proxy/whatever

Edit// Maybe you can change the date usage of the CookieHandler, too? Still uses SDF

 at net.sf.jabref.logic.net.Cookie.<init>(Cookie.java:85)

            at net.sf.jabref.logic.net.CookieHandlerImpl.put(CookieHandlerImpl.java:58)

            at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:728)

            at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)

            at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1536)

            at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)

            at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)

            ... 2 more

[oscargus]

OK, turns out the problem was that the server started to use a two-digit year in the last few days... Now that format is also supported, although, as I understand it, it is not a valid format for a cookie.