-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
date field with non date data generates error #8747
Comments
b like in 10 000 bc? |
well, maybe wrongly, I have been using the date field for information, too, like |
As far as I remember, if you want to put in dates other than in the iso8601 format in that field, you have to use the way around the bibtex editor. |
I believe that in earlier nightly versions I did not received an error message when entering non iso8601 data in that field. |
Hi, I have found that this issue is due to
|
@LIM0000 Thanks for looking into this. As I was recently working on the DateTimeFormatter stuff for imports, I rememebred that we have this Date.parse class (from org.jabref.model.entry;) See also the TemporalAccessorPicker |
@Siedlerchr Thank you for your comment. Proposal solutionIf user's input cannot be converted from I have also tried to look into |
Hmm, I would greatly appreciate if non standard information is still allowed. Specifically I am thinking of information like `forthcoming` or `submitted`. But other users may want to use the field differently. If we do not want such information there, a popup would ideally inform the user on where else to submit such information.
--
Sent from my LineageOS device with K-9 Mail. Please excuse my brevity.
On 7 May 2022 05:12:35 CEST, Sim Teck Lim ***@***.***> wrote:
***@***.*** Thank you for your comment.
…I have looked into this issue again and come up with a solution.
## Solution
If user's input cannot be converted from `String` to `LocalDate` by `LocalDate.parse()`, a dialog box pops up to inform user that the date pattern is unrecognizable. Previous date info will be restore in date field if there is any. Downside of this solution is that user not able to store any non date data into date field. Should we allow user to store non date input into date field?
I have also tried to look into `Date.parse` (from org.jabref.model.entry.Date) and could confirm that `LocalDateTime.parse(value, defaultFormatter)` could cover all patterns (in org.jabref.model.entry.Date) class.
--
Reply to this email directly or view it on GitHub:
#8747 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
There is a tradeoff between:
@ilippert I am not quite sure what prevents you from creating new custom fields like "forthcoming" or "submitted"? (I know you already have some custom fields and know how to do it). Would that not be a workaround? Is it because these new custom fields are not detected by standard citation styles and you would want them to show in your final document? Sorry, just curious. |
related: #2753 |
I agree with @ThiloteE here. This information should NOT belong in the date field. for example for the status there are extra fields 4.9.2.11 Publication State, biblatex manual
|
Ah, Christoph, I do not have an opinion on this yet xD I just wanted to mention the tradeoff and was curious if this could be solved with a workaround. I was not aware What do you mean with "this information should belong in the date field"? - What info exactly? |
I meant "NOT". Edited my comment. |
Thank you for the comments. |
Hi, ok, just looked at the biblatex and biblatex-chicago manuals. The latter also prefers like the biblatex manual the use of Anyway, moving forward, I think for the date field:
However, as a user, I want to be free to add, say, something like So, the first option is that JabRef trusts the user that they know what they want to input, while the second option risks forcing a date on the user, while the user might not want a full date at all. |
There are options in between, I'd say. So maybe inform the user that the action they are trying to do is not recommended and allow them to proceed anyway after acknowledging this. (If there are really use cases where this option is needed and that are acceptable) |
Well, maybe far too demanding, but a great popup would consist of
|
Hi @ilippert , can you please assign me this issue? |
The issue is now fixed and as a side effect the chooser also can display negative dates (BC) |
JabRef version
Latest development branch build (please note build date below)
Operating system
GNU / Linux
Details on version and operating system
JabRef 5.6--2022-04-25--5c9d898 Linux 5.17.4-200.fc35.x86_64 amd64 Java 17.0.2 JavaFX 18+12
Checked with the latest development build
Steps to reproduce the behaviour
b
Appendix
...
Log File
The text was updated successfully, but these errors were encountered: