year in \DeclareLabeldate

[moewew]

To me it seems that \field{year} in \DeclareLabeldate does more harm than good. The fact that labeldatesource can have the value year and does thus not always follow the scheme of giving the date field prefix makes for some really unfortunate edge cases.

This breaks at least labeldate resolution if \field{year} is given precedence over \field{date}.

Could we not simply abandon \field{year} or at least make Biber output \field{labeldatesource}{} instead of \field{labeldatesource}{year}?

[plk]

p. 148 of the doc addresses this - empty or undefined labeldatesource already have special meanings. As I remember, it was explicitly requested to add year to this for backwards compat ... whatever we do, we need to decide now as SF upload seems to be fixed.

[moewew]

Mhh, I just think that the value \field{labeldatesource}{year} serves no purpose and does more harm than good. I can see that \field{year} would be needed for backwards compat in \DeclareLabledate, but I fail to see that \field{labeldatesource}{year} would be needed for backards compat reasons. In fact all styles on CTAN that use labeldatesource don't fare particularly well with \field{labeldatesource}{year}.

Let's leave it at that for the moment and try to release 3.11 now. We can think about this and the implications afterwards. I'm sure I'm missing something here at the moment, and I would not like to take hasty decisions now that need to be rolled back later.

Do you plan to upload biblatex and Biber to sourceforge at the same time? Or can we defer biblatex uploading until the Biber binaries are built?

[plk]

I will defer as sometimes it takes a while for biber builders for cygwin/solaris/freebsd to upload.

[moewew]

OK, good.

Before biblatex 3.11 is released we probably need to update the compatibility matrix in the docs and adjust the release date in the change log.

[plk]

It's done - biblatex 3.11 and biber 2.11 on major platforms is on SF, I will wait until the other biber binaries are there before uploading to TL. SF is still being a bit flakey - they tell me it's due to their major hardware upgrades.

[moewew]

Thank you very much.

[moewew]

I've been looking at this again.

My main motivation here is that biblatex should not care whether a year came from a year field or from splitting up a date. There is no useful information to be gained from knowing that.

To most intents and purposes \field{labeldatesource}{year} and \field{labeldatesource}{} mean the same thing. So at least, I would like Biber to output \field{labeldatesource}{} instead of \field{labeldatesource}{year}.

What should be done on the \DeclareLabeldate side is a bit less clear to me.

• Surely, \field{year} must continue to work for backwards compatibility.
• Ideally, a user should not have to set both \field{date} and \field{year}, since for biblatex. Using \field{date} alone should be enough to catch \field{year} as well. Of course that could cause issues for those who explicitly use \field{year} and \field{date} in different positions. I can't think of a reason why that would be useful, though.

The effect from the last bullet point can be seen in

\documentclass[british]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{babel}
\usepackage{csquotes}

\usepackage[style=authoryear, backend=biber]{biblatex}

\DeclareLabeldate{
  \field{date}
  \field{urldate}
  \field{year}
}

\usepackage{filecontents}
\begin{filecontents}{\jobname.bib}
@book{appleby,
  author  = {Humphrey Appleby},
  title   = {On the Importance of the Civil Service},
  date    = {1980},
  urldate = {2010},
}
@book{bppleby,
  author  = {Humphrey Bppleby},
  title   = {On the Importance of the Civil Service},
  year    = {1981},
  urldate = {2011},
}
\end{filecontents}

\addbibresource{\jobname.bib}


\begin{document}
\cite{bppleby,appleby}
\printbibliography
\end{document}

To me the result is counter-intuitive.

[plk]

Alright - I think this is a good idea. What about putting in a default driver source map to covert year to date, that way, we can get rid of year in DeclareLabeldate too?

[moewew]

That would be a very elegant solution, but I think it would be problematic in case people use non-numeric year fields. For example

\documentclass[british]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{babel}
\usepackage{csquotes}

\usepackage[style=authoryear, backend=biber]{biblatex}

\DeclareSourcemap{
  \maps{
    \map{
      \step[fieldsource=year, final]
      \step[fieldset=date, origfieldval, final]
      \step[fieldset=year, null]
    }
  }
}

\usepackage{filecontents}
\begin{filecontents}{\jobname.bib}
@book{appleby,
  author  = {Humphrey Appleby},
  title   = {On the Importance of the Civil Service},
  year    = {1980-1},
}
\end{filecontents}

\addbibresource{\jobname.bib}


\begin{document}
Lorem
\cite{appleby}
\printbibliography
\end{document}

From time to time I see non-numeric input for the year field out there in the wild (for example https://github.com/plk/biblatex/issues/453), so I don't think we can afford throwing non-integer years away.

[plk]

That's no problem, we just make the map conditional on a regexp match for numeric or even 4-digit numeric? I can check the modules we are using and it might also be possible to match on a specific "year" regexp which rules out things out of year ranges too.

[moewew]

But doesn't copying year to date only if it is numeric leave us with the same dilemma? We'd still need both year and date in the \DeclareLabeldate declaration and labeldatesource could still return year...

At the moment all solutions that I can think of either require biblatex or Biber to 'manually' resolve the date/year duality and 'normalise' \DeclareLabeldate and labeldatesource before use.

[plk]

True, there are still situations where a year would be passed through. Unless we map appropriate years into date and strange things into another field and then always delete year in the map ...

[moewew]

Then the new strangeyear field suffers from the same issues. Ultimately my hope was to make the year/date issue as transparent as possible to biblatex styles.

[plk]

Trying to look at some of the older things ... had a look at this again and I agree that we should just get rid of that "year" anomaly if you still agree? The only reason for that I can see is so that you can tell from the .bbl data that the year came from a year field and not date. I don't see how that is useful. If anyone needs this, they can just make a map to copy year to some custom field and then test for the presence of that.

[moewew]

Yes, I still think it is convenient to have a year coming from year treated the same as one coming from date. I can't really see a use in being able to distinguish the two cases, but I can't exclude the possibility that people might want it. Still I'd say that is quite unlikely.

[plk]

Should be addressed in DEV now. Turned out to be more complicated that I thought but it also turned up an edge-case issue with skiplab which has been addressed too.