Multiple publication dates in citations


We are wondering if it is possible to capture, in addition to the “standard” publication date, article-level publication dates in CSL-JSON. A reference for what I am talking about is at the PMC Tagging Guidelines, , here: For example, often articles are published in electronic form before the print publication comes out, and it’s important that this information be captured in the citation.

For example, see this PNAS article in PMC, Note how the citation under the journal banner displays two dates; 2013-01-02 (print) and 2012-12-03 (electronic). These show up in the MEDLINE-format export ( as the two fields:

DP - 2013 Jan 2
PHST- 2012/12/03 [aheadofprint]

We have found the date fields of citeproc-json, described here,, but none of them seems to be a good fit. Further, I noticed that when I included original-date in a sample JSON file, and then round-tripped it through Zotero (import, then export in the same format) that original-date did not survive.

Can we get some guidance on this issue?


Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 5AN.24D-22

I think we need to add a date variable to support this, as we didn’t
consider this case originally.

Two separate issues:
original-date is a perfectly valid CSL variable, it’s just not yet
implemented in Zotero. It does work in citeproc-js, though.
But as I understand it, it’s intended mainly for historical works (like the
1776 in Smith 2001[1776]) and I don’t think it should be used for e-pub
dates or the like.
Would we ever really need the epub date for citations? I’ve never seen this
except when an article hasn’t been published in paper yet. In other words,
I don’t think CSL should be in the business of storing publication history
of an item. I’m not even sure Zotero et al. should, though I’m more open to
be convinced on that point.

+1 to Sebastian’s point – I was going to reply expressing largely the same

Unless the goal is to expand the CSL data spec into a general-purpose
metadata format beyond the scope of citation formatting (which is a whole
other can of worms), a good question to ask when thinking about adding new
variables might be “could this reasonably be used by any existing or
forthcoming styles”?

Chris, I’d be interested to hear more about the technical motivations for
thinking about mapping PMC data into CSL-JSON. If the goal here is to, say,
create a CSL style that could format citations equivalent to the PMC banner
that you referred to, then there’s a nice concrete example to think about
guiding the addition of a new variable (or repurposing of the existing

From my experience, very few metadata providers attempt to provide multiple
accurate dates for journal articles, so any practical use will likely be
less than widespread (and likely further complicated by the existing but
vague original-date variable).


That absolutely is always our question.


We would need it for the NLM citation style, see We have looked, and it doesn’t appear that there is a CSL for this style yet.

Also, we’re anticipating the need for some applications that might want to render citations in the same format as they appear in PMC or PubMed pages or search results. It’s just speculation at this point, but it would be nice if we could use one integrated solution rather than a fragmented one.

Is there a forward-compatibility mechanism built into citeproc-json, so that we could add a new field for this without breaking all of the old citation processors? I tried adding a randomly-named sibling of ‘issued’, and found that zotero did not like it (rejected it when I tried to import), but that citeproc-node/citeproc-js gracefully ignored it.

Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 5AN.24D-22
301-594-2842> -----Original Message-----

CSL currently uses a fixed set of variables. So if we would decide
that a new date variable is needed, we would need a new version of CSL
(e.g. 1.0.2), for which we would have to update the CSL schema and CSL
JSON description.


I tried adding a randomly-named sibling of ‘issued’, and found that
zotero did not like it (rejected it when I tried to import), but that
citeproc-node/citeproc-js gracefully ignored it.

Feel free to report this on Zotero forums. This should not break Zotero
import if done correctly; it should be simply ignored.

Following up on this,

Bruce asked:

could this reasonably be used by any existing or forthcoming styles?

So, the answer is “yes”. As I mentioned, we would like another date field, for electronic publication date (article-level) for the NLM style. Would it be a huge amount of work? What would be involved? Could we help?

Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 5AN.24D-22
301-594-2842> -----Original Message-----

the actual work in adding a field is relatively minimal: adding it to the
specs and to the schema is very little work, adding it to the citeprocs a
little more, but afaik not much, either.
The two things that actually take work is:

  1. See this through in discussion of the next spec update, including making
    the case that this is broadly needed for citations. I’m still unsure about
    that, though the NLM example is helpful. It could also be used, together
    with the absence of a (print) publication date, as an indicator for
    pre-print publication in citations, so that’d be another plus.
  2. It would then also have to be taken up by reference managers and that
    might be more of an issue. I’m not sure how happy they’d be with two
    additional date fields and we’ll definitely do original date of