Support Staff2 Posted by matias on 08 Mar, 2011 08:20 PM
Hi there Kasey
You don't have to know the exact publication dates, and this is
one of the new features in Papers2. Simply click the "Published"
field in the inspector, and choose the accuracy you need, then
enter the date.
I also find this system extremely cumbersome. 99,9999% of the
time I don't need the sumbitted to accepted fields, and they are by
default entered with the date of import, meaning for most of my
papers (not only from Papers1 but also the new), I have these 3
dates, for exp. 29/3/2011, with the published year is earlier.
Disturbing at least!!
+1 for making the default date accuracy something we can set for
the entire library. Manually entering citation data is never fun,
so the fewer things that have to be done, the better (I'm also
thinking here of the balloon that pops up when I try to enter an
Nice that the option is there to have more precise information
if it's needed, though.
Support Staff8 Posted by charles on 30 Mar, 2011 01:25 PM
By default, no date should be entered. When you edit, it shows
the different dates with today's dates but unless you enter
something, these dates won't apply, and they should not show once
you are done editing. Let us know if that makes sense,
Can you be a little more clear charles, that does not make
Those dates are filled during the matching process and except the
year, pretty useless. How to remove/ edit them for the whole
Support Staff10 Posted by charles on 30 Mar, 2011 02:49 PM
Sorry it was not clear this was happening during matching.
Normally, this would be obtained from the repository, but
obvisouly, if it's just the same as import date, this is not
useful. Could you give an example of publication and repository
where this happens so we can reproduce it on our end and see where
the issue is? Thanks!
Support Staff13 Posted by charles on 31 Mar, 2011 05:21 PM
example: J Physiol Pharmacol, matched using PubMed
The matching picked up the correct submitted and accepted dates
for that paper. It did not set a revised date (maybe we need to
make that clearer, but the absence of an 'X' means there is nothing
to be removed, as nothing has been set). Once you are done editing,
you will see only the published date shown. You can choose to see
other dates by using the popup menu on the label 'published', but
only dates that have a value will actually display one.
Now, there might be other aspects of your request that I did not
understand. Please let me know!
Support Staff15 Posted by charles on 31 Mar, 2011 11:16 PM
The fact that a fake date isentered is misleading. The absence
of cross is even more distressing. Just put no fake date and
everybody will be happy.
I agree it's a usability issue. We can't easily make the date
picker widget display no date without things being just as
confusing, but here is a quick peak at Papers 2.0.4. Let me know
what you think :-)
Am I entering things wrongly, or is there a reason that book
chapters don't inherit the publication date of the book they're
part of? This is the case if I create them by clicking "+" on the
Inspector while looking at the book, or if I create them and then
drop them on the "add chapter" area. I can't think how the
publication date of a chapter could differ from the publication
date of the book, so unless I am doing it wrongly this must be a
I agree the "false date" in the date picker is misleading - why not
have checkboxes beside the date options? That way you check it if
you want to set a submitted date, and if you don't, the checkbox is
empty and the (misleading) date picker is not shown.
Support Staff19 Posted by charles on 08 Apr, 2011 02:58 AM
Far better! In grey, rather than solid black, i would not
Good idea, the date picker will appear in light grey if not
defined, in the next version of Papers (within 2 weeks).
It would be great if it was possible to set the 'Published'
field as year only by default. I have to do a lot of manual
entries, especially with book chapters, and every step avoided is
Rather than make that another preference, we made that something
that will be remembered if you keep changing the entry type using
the popup menu, after 5 times, it will set that as your default
(the next time you start editing in the inspector). So basically,
change that 5 times in a row on one entry (you can simply select
the same menu item 5 times on the same date, even if it's already
set), then save the edit, then edit again, you should see all the
date entries set by default to the month-year format. That will
only work in the next update of Papers though, so please be
All this goes in the good direction. The "intelligent default" is a great concept but should be explained in some way to the user. I hope it coul be applied to the choice of columns and width in the collections, so painful to set one by one.
By the way, I installed yesterday manual 204 which was not proposed by the automatic update.
Hi, I am not sure now if the following has been covered already
but I just discovered a HUGE BUG:
Hundreds (!) of my 1500 papers in my library have their
"published" date set to 31.12.xxxx (for all years respectively) and
in almost all of these cases the year is wrong (the correct year
would be the following year). This seems to have happened upon
import from papers 1.97 because there, the publication years for
all these papers are correct.
I made a smart collection filtering out all papers with publication
date 31.12. for all the years, unfortunately there is no multi
editing to fix this issue all at once.
I have some idea what caused this mess: I built up the larger
part of my papers library during my postdoc in Japan, then I came
to Germany and the time zone changed. It seems that the "published"
year in Papers 1.97 jumps from 31.12.xxxx to 01.01.xxx+1 upon
changing the time zone back from German to Japanese time.
So since I imported my old library in the "wrong" time zone, Papers
2 changed all the dates..
Could you please verify this problem and create a quick bugfix? I
guess changing the timezone is pretty common for all
PS: This issue now turns out to cause me a lot of trouble since
I am just discovering the impact on the bibliography of the
manuscript I submitted recently...
Support Staff25 Posted by charles on 20 May, 2011 04:44 PM
Indeed that was a migration bug in one of the earlier versions,
but this was fixed in Papers 2.0.x (can't remember for sure at the
moment), where we would have special cases for dates falling around
Jan 1st. Do you remember when you did the migration from Papers1?
One option would be to restart the migration from scratch, but if
you have added a lot of papers since, then it's not a viable
option, you would lose the new ones. Please let me know how you
want to proceeed. Best is to start a new discussion by sending an
email to feedback at mekentosj dot com, and very
important to put me in cc in the email, using my address
charles at mekentosj do com. Thanks for your patience!
26 Posted by Clever, Guido on 27 Jun, 2011 07:17 PM
I changed the publication year of about 1000 papers by hand now, took me half the day..
A working Import/Export function of (parts) of my library would have saved me a lot of time. When is this feature coming back?
PS: Bought my upgade license now and I am really willing to stick to papers2. So please dont let us wait so long on blue search tokens, author and journal merging, annotations and and and..
Support Staff27 Posted by charles on 28 Jun, 2011 07:00 PM
I changed the publication year of about 1000 papers by hand now,
took me half the day. A working Import/Export function of (parts)
of my library would have saved me a lot of time. When is this
feature coming back?
I am really sorry about that. Like for the blue tokens, and
author/journal merging, I can't give a firm date for the feature to
be back. I should point out though that the archives
Papers1/Papers2 are unlikely to be compatible with each other, I am
Thank you very much for supporting the development of