error in date parsing for serials with format yyyy/yyyy or yyyy-yyyy

Hello, I was helping a friend to start using Zotero, and he encountered an issue with multi-year publication dates -- i.e. a journal that published vol. 3 in 1966/1967 or 1966-1967. When he tried to generate a bibliography, these dates came out in Chicago style as "/67 1966" or "Winter -1975 1976"

It would seem that Zotero does not allow dates with this format, but they are not uncommon. Is there a solution to this problem?

Many thanks for any advice that might be available.

Josh Lupkin
supertaxicab(at)gmail(dot)com
  • There's a ticket from last year to support this, but the CSL processor is currently being rewritten, and Frank, who's rewriting it, would have to comment on whether he's implemented anything along these lines. The basic idea is that dates that aren't cleanly parsed should be passed through to the bibliography as is, and, as support for additional date-related concepts (e.g., approximate dates) is added to CSL, the pass-through will become less and less necessary.

    As an example, though, how would you expect those dates to be formatted in Chicago?
  • Dan:

    Well, I am not sure. I think my patron is just using full note with bibliography, but I should clarify. Perhaps Adam Rogers, “View of Mexico,” Gay Sunshine 39 (1978/79): 639.

    Why not allow an option for manual data entry of year, month, day in separate boxes?

    Thanks!

    Josh
  • Why not allow an option for manual data entry of year, month, day in separate boxes?
    How would that help here? Zotero already automatically parses dates in various formats, so there's no need for manual entry. The problem here is that it doesn't understand multi-year dates. The proposed solution on that ticket is to just pass the full string through if Zotero doesn't understand every part of an entered date, in which case your examples above would just appear in the bibliography as entered.

    I ask about the desired result because Zotero and the CSL processor would ideally be able to understand and dynamically reformat most date-related concepts according to a style's requirements, resorting to passing through the user-entered string only in rare cases. But that requires enumerating the unsupported date-related concepts and their associated style requirements and figuring out whether they're worth adding explicit support for.
  • edited May 20, 2009
    At the moment, the new CSL processor depends on the application (Zotero) to deliver the date information as a structured object with year, month and day attributes, and this clearly isn't good enough.

    It looks like I could do one of three things:

    (1) Extend the CSL input object for date values to include a "literal" attribute, to be filled by Zotero if its date parse fails

    (2) Accept the date field as a literal string, and parse it separately within the processor to produce the same result as (1).

    (3) Do as (2), but attempt to provide range awareness for dates, with extensions to CSL to control the formatting of ranges.

    Of the three, (1) seems the path of least pain and least resistance. Zotero needs to parse the date field for display anyway, and options (2) and (3) would involve code replication. That seems like unnecessary bloat, and could produce disparate results in the display and in CSL output, which would be confusing.

    I'll put that on the TODO list, subject to any objections or suggestions that come back.
  • Dear Dan and Frank,

    This is a great thread, as I too have the need for multiple years in the "date" field. In my case, I need to put the publication date of the book I used and THEN in brackets the year it was originally published. Example: a book was published in 1864, but I have the reprint from 1977, so I want the date to read 1977 [1964]. This a very common way of indicating the original publication date in shorthand.

    This also goes for journals that come out once every two years -- 1979/80. Or an 8 volume set that was published over a number of years, 1979-1991.

    Is there a work-around in the meantime, it is tedious to do all these by hand.

    Thanks for all the great work,

    Daniel Michoin
  • Frank: Zotero might very well want range awareness itself at some point as well, so I think you're right that (1) makes the most sense for the processor. Of course, it might be good for the processor to accept range inputs at some point if there are actually style differences, but I don't know if there are.
  • Seems that this will help useing Hebrew dates
    (see link http://forums.zotero.org/discussion/7093/hebrew-dats)
  • I think it is very important to be able to have an original date and a reprint date stored as separate fields and integrated into a bibliography. So, for example, I would like the following citation in Chicago:
    Ella Lonn, Foreigners in the Union Army and Navy (1951; New York: Greenwood Press, 1969).
    (THe book was first published in 1959. IT was reprinted in 1969, but this isn't a 2nd edition, just a reprint with a new press. It would be good if there were a separate field for each date and if the output could reflect this.
    Thank you! I love Zotero.
  • Just a further thought -- maybe the date field could have a + by it like the author field, with options, like in the author field, for first edition, reprint, etc.
Sign In or Register to comment.