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.

That does sound odd. I'll take a look at this tomorrow (it's getting late in the local timezone).

there's no official workaround, no.

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.

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.

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>

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

Unbelievable! It works! Thanks a lot, Adam.

like, it needs to say "presumed date" before the date? Or it needs to be in square brackets?