A problem with dates...

poirmw

I am running Zotero Standalone 3.0.14 on an Windows XP system and I am experiencing a problem with dates. When I enter 1995-96 or 1995-1996 in the date field, what I get in the footnote is the reverse, i.e., 96-1995 or 1996-1995. The journal in question uses 1995-96. How do I correct this? Thank you in advance. MWP

adamsmith

Currently Zotero does not handle date ranges correctly - I don't believe there is much you can do about that.

poirmw

I think that I can work with a temporary solution until you find the correct one. I just reverse the dates. Since Zotero insists on converting 1995 1965 to 1996 1995, then reverse the entry to read 1996 1995 and then the right dates come up. Then to remember that this will need correcting when the solution is worked out, place a word in Notes to that effect.

Thank you for point out this dating problem. I had not noticed it, but I now see that I have three other entries that need correcting. MWP

Gracile

MHSmith's workaround here might help: http://forums.zotero.org/discussion/6111/2/better-date-field/#Item_14

place a word in Notes to that effect.

or use a dedicated tag

poirmw

Thank you Gracile. I should have thought of this temporary solution. I also searched the forum but did not notice this. MWP

I find it curious that an underscore symbol will produce the right order in dates, while a dash will not. i.e., 2007-2008 does not work, but 2007_2008 does. Why is this the case? MWP

Gracile

Zotero is fooled by the underscore (or any other chars which is not a slash or an hyphen) and can't parse the field as a date (as you can see, there's no date parsing indicator, in grey bold, on the right of the field in this case.)

poirmw

Gracile: Thank you. I noticed the parsing indicators at the end of the line in my other entries, but I had not focussed on the meaning of these nor on the absence in my problem dates or on the slight difference in colour of the indicators. I am generally more concentrated on what I am writing than on the "mechanics" of properly functioning computer programmes, particularly ones that function as well as Zotero. In any case, thank you for pointing this out. I'll pay more attention from now on. MWP

robheimburger

I found a solution to this problem. If I want the date to show as 1993-2010, I enter

2010 1993 to

in the date field, and in the footnote and bibliography, this turns into "1993 to 2010." Using "to" isn't quite correct, but it's clear to a reader.

zrottman

This still seems to be a problem. Has Zotero addressed the issue with year spans yet? Is anyone aware of a work around? A film dated 1971–72 for example.

adamsmith

It's not fixed but there is a workaround. Leave the date field blank and insert date ranges like this in the Extra field:

issued: YYYY-MM-DD/YYYY-MM-DD

i.e. for your example just
issued: 1971/1972

djross3

This is a helpful solution to the problem.

However, I am having a practical problem implementing it: how can I search my library (4,000+) entries for those that have a date range, without going through each of them manually?

If I sort by date, it doesn't show this. If I export as CSV, BibText, etc., it is converted to a single year. If I search, I am only allowed the "before/after" type options, rather than searching for a literal character in the field.

Is there any way to search for all items with dates that are not exactly "YYYY" as literal text? (At least for my library, I have few months/days, so I could easily sort through the remainder manually.)

bwiernik

You can enter a date in the actual Zotero field if you want as well (it will sort on the first year)--the citation processor will override the Date-field value with one from Extra if provided.

I'm not exactly sure what you want to search for, but I don't believe there is a way to search for whether dates have non-year parts in them. But I wouldn't both trying to fix these entries right now, but rather just wait until you are actually trying to cite them, then you will see that they have an incompletely-parsed date and can fix it then.

djross3

You can enter a date in the actual Zotero field if you want as well (it will sort on the first year)--the citation processor will override the Date-field value with one from Extra if provided.

Yes, thank you. I am doing that now. I'll just put "1999-2000" in both the Date and extra/issued fields, so it'll work for both.

I'm not exactly sure what you want to search for, but I don't believe there is a way to search for whether dates have non-year parts in them.

I'm trying to find the places where (e.g.) "1999-2000" was entered, so that I can correct the shortcoming of Zotero's parser by placing it in extra ('issued: ...').

I'm not exactly sure what you want to search for, but I don't believe there is a way to search for whether dates have non-year parts in them. But I wouldn't both trying to fix these entries right now, but rather just wait until you are actually trying to cite them, then you will see that they have an incompletely-parsed date and can fix it then.

Given that Zotero will never inform me of that notation, such as when entering it in a document, I don't see why waiting will be of any help. I'm preparing to put my dissertation together which will have several thousand references (4,000+ stored currently), so I won't be easily be able to skim over the bibliography. More importantly, there will be no obvious sign of anything missing because instead of "1999-2000" it will just say "1999", which looks correct unless I happen to remember that particular reference had a complex date. I have already of course fixed those for which I remember there being complex dates, but I can't remember all of my references, which is why I'm using Zotero :)

It is quite odd that the information cannot be extracted from Zotero in any way (I've tried a number of things) despite being displayed in the editor. The information is stored the in the .sqlite database file, but without actually parsing that into a database I can view, searching it in a text editor is not feasible (too many false positives, especially when all dates appear to be stored as "YYYY-00-00" as a default for example).

In short, there seems to be no way to figure out which entries I entered over the past 3+ years as "YYYY-YYYY" except looking at all of them (when going through the entries, the date field jumps around because the other fields change, so I can't skim it visually that way either).

The way that Zotero handles dates really is bizarre. On the one hand, I appreciate that it doesn't completely block entering literal text in the date field, but at the same time, it is so convoluted trying to deal with it (e.g., no way to search!) that perhaps it should. Finally, to make things even more confusing, the value from an exported CSV doesn't match exactly what is displayed in the sorted display in Zotero (it says "forthcoming" in the CSV for example, versus "0000" in Zotero), so there are at least 3 different date values that are used in different ways.

And even less sensibly, a date of "forthcoming" will be displayed as "0000" in the Zotero middle panes, but sorted last after all actual dates (e.g., 1999, then 2000, then 2018, then '0000'). Yet when actually used in a bibliography (either in the style preview window within Zotero or in a document elsewhere) the literal text "forthcoming" will be displayed, but it will be sorted first.

In short, none of that behavior makes any sense. Why does "issued" in extra behave differently from the "Date" field when it is the same variable? (What is the advantage of Zotero's "help" in parsing it?) Why does sort sort "0000" last (in Zotero's middle pane), but sort "forthcoming" first (in a bibliography)? Why can't I search or export "Date" in any literal way? Why does "Date" allow for text input if it is fundamentally ignored and altered by the software, but then still display the original text input when re-viewing the entry later?

Sorry for the long ramble here, but I've been manually correcting my data for hour after hour now (not only, but especially for this). The way this works is very confusing, presumably the result of trying to make compromises in the software that haven't been completely sorted out. It is now clear to me that literal text does not belong in the date field, at least not without a backup,* but I can't even figure out how to get it out of that field consistently without losing data I originally entered.

[*Specifically my plan is to do what I can with a mix of the Date field and 'issued' in extra, and then for anything outside of that, make an additional annotation reminding me to do manual correction later.]

djross3

I didn't have any way to view the .sqlite file on my computer, but realized I could probably find some software to do it, and here is some that seems great: https://sqlitebrowser.org/

However, now that I look at the structure of the database, it is quite indirect. There is no table of entries with the values. There is just a single table "itemDataValues" with thousands of entries, each marked by ID and value, with ID corresponding to the data structure for each item as stored in another table. This means (1) I can't view only the dates (but instead all of the data from all of the entries); and (2) I can't view the dates in the context of the entries with which they are associated.

Regardless, it is interesting (regarding the sorting questions above) looking at how the data is stored.

For an item with a date range, it looks like this:
1966-00-00 1966-1969

And for a literal text entry, it looks like this:
0000-00-00 forthcoming

Extra, of course, is just stored literally:
issued:1966-1969

I still don't understand how that relates to how it ends up sorted or getting parsed in the styles (obviously the "0000" is taken as the value instead of the literal text), but at least it's a little clearer what's happening now in the software.

Also, curiously, only one unique instance of each value, thus shared by different items in the library that have the same value. I guess that saves space (makes sense), but also makes it harder to track where things are.

(Anyone who has worked with the program's source code probably already knows this, but it might help for those like me who didn't know what was going on behind the scenes.)

Anyway, short of writing PHP code (and installing this data into a database on a server), I still don't see how I can locate the records that have complex dates in them. (The "forthcoming" ones are easy because they're sorted as "0000", so that's not a problem.) I guess I'll keep poking at it!

Edit: OK, it's possible to go through it, just very slow. Here are the steps:
1. Copy the entire 'itemDataValues' table from the SQL reader software.
2. Paste into a new Excel document.
3. Sort by the second ('Values') column.
4. Skim through for possible matches to whatever you're looking for (in my case, numbers treated as text by Excel, e.g., "0000-00-00", and specifically in realistic date ranges, e.g., "1900...."). [Note: sorting in this way allowed me to identify a range from among the 15,000 total values in my database to just about 500 that are in the range of "1900-00..."-"2018-00...", which is reasonable to look through manually. Slightly more helpful is copying that column into a plain text editor, doing find>replace for '[space]' with '[tab]' and then copying back to Excel which will split the column in two following the spaces after, e.g., '1900-00-00' and show the range, e.g. '1900-1901'.]
5. When you find an entry that looks likely, there are two options. You can track it through the database structure [*see note below for how], or much more easily you can simply type it into the (simple!) search field in Zotero to bring up all matching entries.**
6. Open a full CSV export of your Zotero library in Excel (export one if you need to)
7. Locate the relevant item by "key" in that spreadsheet.
8. Go back to Zotero and fix whatever information in the original entry.

Horribly, horribly slow, but I need to find these entries. At least there aren't too many of them.

There really needs to be a better way to do this!

...but this works (kinda) if anyone else is in the same situation as I am....

--

*Long instructions for locating an item by tracking IDs through the database:
A) Go back to the SQL reader
B) Look up that ID in the 'itemDate' table, searching for the ID in the valueID column.
C) Note the ID for the item
D) Look up that ID in the 'items' table, searching for the ID in the itemID column.
E) Copy that item's "key" (from the 'key' column).

--

**OK, this is the most bizarre thing I've discovered yet. Searching for the literal date actually works, IF you already know what to search for. So another option would be to search, e.g., all combinations of numbers of the pattern "n-n" in the field (or more strategic versions of that) until you find all entries for dates, if that seems faster than going the route of the database.

Now, answer me this: why can you search the date field's literal text through the simple search, but not restrict it to that field in the advanced search????All that would be required then would be searching for "-", but now that can't be done, so it takes all of this work.

The design of the date field in Zotero really is crazy. It half does a lot of things.

djross3

Conclusion: The method outlined above works. It's slow and indirect, but it works. If anyone else has the same problem I did, you can follow those steps.

I was able to identify about half a dozen entries that I would never have found otherwise. Worth it. Not fun.

Ironically, now that I understand all of this and have fixed my library so I'll never had to do it again, it would only take me about 30 minutes now to redo all of that, after knowing what I know now.

Lesson learned: if you put a non-numerical, literal text value as "Date", always make a not in "Extra". (Or of course find some alternative. But the note will at least allow you to find it later!)

bwiernik

(I don't have the time to read multi-page posts, so if you are looking for feedback on anything, I really need you to condense to a few sentences.)

Yes, thank you. I am doing that now. I'll just put "1999-2000" in both the Date and extra/issued fields, so it'll work for both.

Note that this is not the format you need to correctly format date ranges. Like adamsmith said, you should use:
Issued: 1999/2000

(or Issued: YYYY-MM-DD/YYYY-MM-DD if you want month and day, too)

djross3

Summary of the above: simply a long set of directions on how to actually go about "searching" (indirectly) the full text of the date field, given that Zotero provides no options for searching it directly nor exporting as literal text. No need to read it, except to follow those instructions (for anyone else who comes upon this thread and wants to know how).

Note that this is not the format you need to correctly format date ranges. Like adamsmith said, you should use:
Issued: 1999/2000

Both formats seem to do the same thing.

In some styles, they're both rendered as "1999/2000", and in other styles they're both rendered as "1999-2000".

Actually, I find these to be semantically different: "1999-2000" would refer to a work that was published over two years (perhaps in multiple parts, most commonly for a multi-volume book), whereas "1999/2000" refers to a single item condensed to represent two years (most commonly for a single volume of a journal that is skipping a year in its publication history).

But I'll go ahead and change the few in my library to the slash format in case that helps with forward compatibility later. Thanks for catching that.

(Note: yes, it works for full dates, or apparently also mixed formats like "January 1-2, 2018".)

bwiernik

The citation processor interprets 1999/2000 as meaning "a date range starting in 1999 and ending in 2000". "1999-2000" is passed literally as a string, so it won't be correctly formatted according to style requirements.

djross3

Hm. Now I'm not able to reproduce what I thought I saw earlier with slashes coming out in some of the dates in some styles.

Anyway, yes, that works fine. Oddly it ends up formatted with dashes rather than slashes in all styles from what I'm seeing at the moment.

No objection from me, I'll use the slashes, thanks!

monika.barget

Dear all, is there any news on the date range front?

I am collecting websites of RI / DH projects in ZOTERO and want to indicate the whole funding / update period of each project as "publication date".

Here I have put "2019/2020" in the date field and it comes out like this in Chicago Manual Style:

*GFBio – Gesellschaft für Biologische Daten e.V. 2019. „The NFDI Consortium for Biodiversity, Ecology and Environmental Science“. 2020 2019. https://www.nfdi4biodiversity.org/.*

Using "issued:2019/2020" in "extras" works, indeed:

*GFBio – Gesellschaft für Biologische Daten e.V. 2019–2020. „The NFDI Consortium for Biodiversity, Ecology and Environmental Science“. 2019–2020. https://www.nfdi4biodiversity.org/.*

But I still have hope that the date field parsing will be changed at some point. :-)