10

This is a general (hope not too general) question concerning the (future) use of the year and the date fields in biblatex.

The short version of this question might actually be: "Is it likely that the year field will at some point be deprecated and should I switch to using date?"

But I'm actually curious about it more generally. The biblatex manual strongly encourages the use of the date field over the year field. However, I've been faring fairly well so far with using year. I rarely need month and day, or some of the other fancy stuff like eras and things, so for reasons of economy, I have found it easier so far to only use the year field and then for the occasional "in press," "forthcoming," or "no date" to use

Year = {\bibstring{inpress}}

for example, as opposed to leaving Date blank and giving

Pubstate = {inpress}

(since date = {inpress} or date = {\bibstring{inpress}} don't work). Having a year together with an origdate field also seems to be working fine (at least for biblatex-chicago's author-date specification). So at this point I don't see a reason to change my database to date. However, is there any particular reason why I shouldn't use year? Will it likely be deprecated in the future?

jan
  • 2,236

1 Answers1

7

While biblatex has made its fair share of backwards incompatible changes (prime example: Biblatex 3.3 name formatting, but I don't think there have been many incompatible changes w.r.t. the input in the .bib file) I think it is fair to assume that year will continue to be supported in .bib files for the foreseeable (and unforeseeable) future. Still using date over year is encouraged and it is a must if you want full dates with day precision or date ranges or negative years.

What I can not guarantee is that

year = {\bibstring{inpress}},

will continue to be supported. At the moment legacy year and the preferred date fields have to be treated separately in some definitions. That is a source of confusion and frustration for some and also a pain to maintain (cf. https://github.com/plk/biblatex/issues/714). Additionally sorting can be a pain and outright break if fields that are normally numeric in nature (years) come along with string values (https://github.com/plk/biber/issues/228).

Arbitrary input in year could be problematic, I would only rely on numeric input being supported in the future.

With a bit of tweaking (admittedly, for biblatex-chicago that might actually mean a lot of tweaking, you can of course contact the maintainer about this, I'm sure he will look into proper pubstate integration if he can find the time)

pubstate = {inpress},

should give you an output very similar to

year = {\bibstring{inpress}},

and it is also more semantically sound, and shorter because you don't have to type \bibstring all the time.

For the standard styles

\DeclareLabeldate{%
  \field{date}
  \field{year}
  \field{eventdate}
  \field{origdate}
  \field{urldate}
  \field{pubstate}
  \literal{nodate}
}

is enough to display the pubstate in citations. To mimic what mergedate does you could then also add

\renewbibmacro*{addendum+pubstate}{%
  \printfield{addendum}%
  \newunit\newblock
  \iffieldequalstr{labeldatesource}{pubstate}
    {}
    {\printfield{pubstate}}}

to avoid duplication of the pubstate information.

moewe
  • 175,683