CSL not processed correctly for date range workaround

I'm using "sbl-fullnote-bibliography.csl" and Zotero standalone 3.0rc1.1.

Because of the lack of date-range support in Zotero I've started to use dates like "_1896-1905_" to force Zotero to treat them as string. The macro "issued" should print this date string with the following lines, but there is no output:

<else-if type="bill book ..." match="any">
<date variable="issued">
<date-part name="year"/>
</date>
</else-if>

The output is OK if "date" is changed to a date that Zotero recognises automatically (e.g. "1896").

And, more importantly, the output is also OK, if any further variable output is added to the beginning of the macro "issued"! E.g.:

<text variable="title"/>

Any thoughts on this?

Thanks!
  • edited January 30, 2012
    (Sorry, I posted a response to the wrong post earlier. Reposting below.)
  • This would be an issue with date parsing in Zotero itself (not in the citation processor, which is my end). I believe that the core developers are planning to make some changes to the date parser, and to date handling generally, but I don't know the timetable.
  • Thanks for the quick response, Frank! Once Zotero has implemented date ranges, the workaround I'm using won't be necessary any more.

    But I believe that the issue I've described above has nothing to do with the date parsing itself. Whether the anomaly of the output (see description above) is due to the csl parser or whether it is a Zotero bug that only comes up when the content of year is a string, I don't know.

    I found a second way of getting Zotero to add the date string "_1896-1905_" to the output: by replacing "<text macro="issued" />" in the macro "issued-note" with the exact content of the macro "issue"! Is there any reason why that could cause a different output?
  • That does sound odd. I'll take a look at this tomorrow (it's getting late in the local timezone).
  • Hello,

    I'm tuning a CSL document for my wife, who fell in love with Zotero. I've sorted out most of the things, but now I'm hitting the same problem with date ranges. Things like 1994-1995 are not handled correctly and show up in the text as "1995 1994" (as I understand the date format expected is dd-mm-yyyy). After quick search on this forum I'm rather pessimistic :(

    I tried Rene's workaround with the same results. It seems that a date varibale can't be outputted as text (results in null string).

    As I understand CSL 1.0 now supports date ranges and this is Zotero specific issue. Is there any official workaround for this?

    best regards
    Miron
  • there's no official workaround, no.
  • Thanks for prompt reply! For the sake of future generations looking for this answer... what are the plans to solve this issue? Could you recommend any specific place to follow it?
  • Better date-treatment, including for date ranges, original dates, "circa" dates, BC dates etc. is planned in general. I believe the hope is still Zotero 3.5 for that, but Dan would have to say.

    Since this is tied with a lot of issues, I don't think there is a ticket to follow, though, no.
  • The headline issue has been languishing, sorry. The likely cause is a failure of the parser to identify that there is output coming up when the input is a string rather than a successfully parsed date. I'll take a look and post back when I've tested for this.
  • edited March 21, 2012
    Sure enough, that turned out to be the problem. Zotero is passing through unparsed dates to the processor, and the processor was rendering them unless they were the sole variable rendered inside a CSL group.
    <group delimiter=": ">
    <text value="date"/>
    <date variable="issued" form="text" date-parts="year"/>
    </group>

    In such cases, the processor was seeing the group as producing no output, and quashing everything inside it. I've fixed the problem in a fresh processor release (1.0.305). When that is picked up by Zotero, this problem will go away in the next Zotero release. Sorry for the inconvenience; this was an oversight on my part.
  • Fantastic! Thanks a lot!
  • edited April 5, 2012
    Frank, this bug might be related to the one you fixed recently:

    The suffix "." given in a layout block is not printed in the following case, even though the macro "access" produces no output.

    <layout suffix=".">
    <text value="Some text" />
    <text macro="access" />
    </layout>

    <macro name="access">
    <group delimiter=" ">
    <if variable="URL">
    <text variable="URL" />
    <text value="other output" />
    </if>
    </group>
    </macro>


    If the group tags or the if tags or the two text tags are removed within the macro, the layout suffix "." is printed correctly.

    My current workaround is an empty group within the layout:

    <layout suffix=".">
    <group>
    <text value="Some text" />
    <text macro="access" />
    </group>
    </layout>
  • This would be a separate issue. I think I understand your description. The problem is that a trailing top-level block that produces no output causes the layout suffix to fail? If so, that might well have slipped through in testing (I'm away from the computer this morning, will check it later).

    The best CSL coding practice uses nested groups and delimiters to join all output blocks (rather than joining with affixes), because that assures there will never be hanging or duplicate punctuation. If groups are used for all inter-cite joins, the cite as a whole will always be enclosed in an outermost group, as in your "workaround", and there will be no lone trailing group.

    That said, this should work. If I can reproduce the fault, I'll fix it up.
  • edited April 25, 2019
    To pick up the words of mkobelski ("For the sake of future generations looking for this answer..."):

    Although I'm not certain if I can already speak of a future generation, I stranded on the "date-range" issue. Ranges such as "1840-1841" or "2014-2015" get cited as "1841 1840" and "2015 2014".

    The workaround works: replacing the hyphen with an underscore in the metadata (2014_2015) and than later, in the final fase after unlinking all citations in my Word document, manually replacing all underscores with a hyphen. (I got inspired by discussion 40880)

    But, talking about official workarounds, my question is this:
    Has somebody, in the meantime, found a way to tell Zotero, in its library, that I want the date to show up as a string (or must I say "literal"), without adding underscores that in fact do not belong there, so I would not need to unlink and do the manual replacing of these anomalies? I tried quotes, double quotes and curly brackets, but none of these seem te avoid Zotero from defining the input as a date (y m d) instead of not defining it, so it comes out literal. Underscores before and after do the trick (_2014-2015_) but then the literal field also shows these underscores in the citation, leaving us where we already are (i.e. manual fixing after unlinking).

    I believe to understand this is not a CSL issue, because if I export my source as JSON I can type, in the source code, whatever I want in the "literal" field and it comes out just like that. I simply wonder how I can make "2014-2015" appear in the "literal" field from the Zotero library and the customisable metadata thereof, so it appears correctly in my Word doc.

    Thanks for helping me out.

    Willem
  • I don't know for any literal date pass-through, but for date ranges, you can get them by adding them in EDTF format in the Extra field preceded by "issued:" like so:
    issued: 2014/2015 This will also work for day or month ranges, along the lines of issued:2014-04-22/2014-04-25
    I think this actually might do literal pass through in technical terms and the date is then interpreted by the CSL processor as a range.
  • Unbelievable! It works! Thanks a lot, Adam.
  • Thanks for your previous help, Adam! I have an additional question: I have a document that is not dated, but has presumed dates of 1919-1920. If I put it in the date range box, the problems describe above appear. If I put it in the extra box, only the 1919-1920 shows up, without indicating that it is a presumed date. Any way to get both words and numbers to accurately show up? Thank you!
  • like, it needs to say "presumed date" before the date? Or it needs to be in square brackets?
  • I have had a lot of trouble with date ranges in Zotero and just came across this thread. The solution works well. But Zotero really needs to make this feature more transparent.
Sign In or Register to comment.