Add datelabel = year option setting

[aboruvka]

Author-year styles don't consider month or days in the labels. Considering that, could a datelabel = year option setting be added? It perhaps should become the default given that the standard citation styles print only labelyear+extrayear.

[plk]

Yes, I noticed this when looking at the labeldate stuff. I think we should use datelabel=yearonly and make this the default. It needs changes in a few places in the tangle of date macros. Do you have time to tackle this?

[aboruvka]

Sure, I'll take a look on the weekend. But it seems I'm confused. Can you remind me what the rationale was for adding labelmonth and labelday in the first place? Only the years are considered in sorting and disambiguation via extrayear, so the "label" prefix is a bit of a misnomer.

[plk]

Some people wanted to have months etc. in the bibliography label in authoryear styles and wanted to be able to select the month (from urlmonth, eventmonth etc.) just like labelyear. That is, they wanted a fallback list of possible month labels like labelyear. So, I generalised the interface to allow this. This means that \DeclareLabeldate selects the source of years, months and days. However, I agree that the default in authoryear styles probably shouldn't be "comp" since the authoryear citation labels don't include months by default.

You're right that sorting by default doesn't use month/days - another reason we should switch to "yearonly" for authoryear. However, a user could define a sorting scheme which sorted using month, day etc. if they wished.

[aboruvka]

I had a look, but it doesn't seem a tidy solution exists without backend changes. Default labels should be labelyear+extrayear regardless of the backend. datelabel is biber-only. Under bibtex date labels are labelyear since labelmonth and labelday are undefined, but months get introduced into bibliography date labels via mergedate settings. Another problem arises in entrysets. Under biber the subentries have no individual labelyear. With the recent shift from year to labelyear in date+extrayear, the same date label is erroneously printed for each subentry. Under bibtex subentries have their own labelyear defined.

\documentclass{article}
%\usepackage[backend=biber,style=authoryear]{biblatex}
\usepackage[backend=bibtex,style=authoryear]{biblatex}
\addbibresource{biblatex-examples.bib}
\begin{document}
\cite{stdmodel,bertram,shore}
\printbibliography
\end{document}

[plk]

Hmm, this is partly due to a bug - I had forgotten to add new label* fields to \resetdata and so they were not getting cleared for sets. I'll fix this.

The other issue is that bib labels now always use labelname(labelyear) now so that they match citations which always use these. The bibtex behaviour is an anomaly since the backend is supposed to enforce "skiplab" on set members which means they should have no labelyear. The problem is that the new date printing doesn't fall back on plain year fields, like it should. I'll look at this too.

[plk]

I've looked at this and uploaded 2.7b to the DEV folder (same as dev branch). Perhaps you can check? authoryear style now falls back to year if labelyear isn't defined because set members never have labelyear defined.

[aboruvka]

I think that solves the second problem I mentioned, but not the first. We can define and set datelabel=year as the default, but this won't impose year-only labels for any entry under bibtex and for all subentries with entrysetcount > 2 under biber.

[plk]

I think for bibtex, I made \printdatelabel do the same as \printdate so all we should need to do is to provide two new options - date=yearonly and datelabel=yearonly ? The entrysetcount > 2 thing - do you have an example with biber?

[aboruvka]

I don't think it is safe to assume that users will always want \printdate to output the same format as date labels. For the entryset issue see the document below.

\documentclass{article}
\usepackage[backend=biber,style=authoryear,date=long,datelabel=short]{biblatex}
\defbibentryset{online}{itzhaki,markey,wassenberg}
\addbibresource{biblatex-examples.bib}
\begin{document}
\cite{stdmodel,bertram,shore,weinberg,online}
\printbibliography
\end{document}

One way around this is to force \printdateextra and \printdateextralabel to have the same format (and by default output only year+extrayear or labelyear+extrayear, respectively).

[plk]

My assumption was that users would more often than not want the bib main date in authoryear styles to match the cite labels so that they can find the bib entries from the citations more certainly. I can't think why anyone wouldn't want them to match since that's the point of a citation? You're right that the set example looks a bit messy and there is certainly a case for making everything "yearonly" by default - this would force the same format for \printdate* macros. Do you think this is enough?

[aboruvka]

Mis-matched labels are a result of the mergedate option setting. Only years everywhere is consistent, but loses information. Presumably PL wanted to offer a way to retain date information while avoiding repetition. But yes, most author-year styles consider only years.

\printdate* are user-level commands, so we shouldn't make the broad assumption that these are always being used to print labels in every variant of an author-year style. It probably is safer to impose the same format on \printdateextra* rather than all \printdate*, since extrayear is used exclusively in labels.

[plk]

Hmm, I'm not sure what to do about this. The authoryear example doc says "Since this style prints the date label after the author/editor in the bibliography ..." it seems that there is a case for defaulting to label fields in the bibliography but I see your point. Enforcing the same format - I assume you mean enforcing that the options datelabel = date?

[aboruvka]

Yes, the best solution here isn't obvious. I was thinking of revising datelabel so that it would specify the format of both \printdateextra and \printdateextralabel, since these are the commands used to set all date labels in the bibliography. date could control \printdate and \printdatelabel. A better name for datelabel in this case would be dateextra.

However I'm just trying to suggest something that would impose minimal changes on the post 2.5 setup. mergedate was intended to reduce repetition between labelyear and date - not any of the fallbacks for date. The introduction of labelmonth and labelday seems sensible, but it complicates things - the difference in backends is larger and mergedate is now only handling a small part of the potential redundancy in dates.

[plk]

Just to be clear - the MWE above - the issue there is just that we can have date not the same as datelabel so that the date labels in the bib for sets and set members don't look the same? I'm wary of splitting date/datelabel as you suggest as then an option which works for bibtex (date) is rather strange as it would control \printdatelabel which gets its information from a biber only setting (\DeclareLabeldate). How about renaming date to dateformat, datelabel to datelabelformat and then using date to set both, to retain backwards compat and to force everything to the same by default?

The issue of citation labels not exactly matching the bib labels because of mergedate settings has always been the case so I suppose were not concerned with that.

[aboruvka]

The issue is that, depending on the backend and entryset membership, some bibliography date labels get printed by \printdateextra rather than \printdateextralabel. The format of these can be made different with the date and datelabel option settings. Your suggestion raises a problem if anyone wants to use \printdate to just print dates, not date labels. This is why I raised the idea of imposing the same format (default to year plus extrayear) on \printdateextra and \printdateextralabel (not \printdate). However if you're OK with that problem, then I wouldn't bother adding the format suffix - there is also urldate, origdate, etc. Just retire datelabel.

mergedate settings should be a consideration here because (1) the new defaults should ensure that the citation and bibliography date labels match and (2) labelmonth and labelday are being pulled from fallbacks for date, so under biber dates in bibliography entries don't avoid all that repetition mergedate settings were devised to avoid.

[plk]

Sorry, my mind is a bit scrambled this week and so I apologise if I'm not understanding. I think \printdate always prints dates and not labels - it calls one of the \mkbibrange macros and they only use the label fields if you call \printdatelabel (see \DeclareBibliographyOption{datelabel} in biblatex2.sty).

With mergedate, the problem might be that the date label is generated from something other that the DATE field but with most merge options, it's DATE that is cleared when merging. So the problem is more confusing merging than repetition I think. What we could do is clear the right date field instead of always DATE in the mergedate macros. This might result in strange things like "retreived on" and then blank however. Another option is to only clear DATE in mergedate when the label is based on DATE. Then you don't lose information. In any case, such instances are pretty odd anyway, using EVENTDATE, URLDATE or ORIGDATE etc. as the label and people might be expected to do a bit more coding to make sense of this?

[aboruvka]

No need to apologize. I don't think it's you - the problem is confusing and I'm probably not being very clear. The issue I'm trying to raise is that if we impose date=datelabel and by default set these to yearonly, the user-level commands \printdate* can no longer print full dates.

Instead of using \printdateextra and \printdateextralabel in authoryear.bbx, perhaps we should just stick to a variant of \printdateextralabel that tests for availability of labelyear for us. When not available, it draws from date. The datelabel option setting can then be extended to bibtex.

The mergedate problem could be left as-is in the standard styles. But it could be easily addressed if you were to give me a new field - say datelabelsource - that provides the prefix of the field used to construct the date label (e.g. event, orig, url).

[plk]

Agreed - we shouldn't be using the vanilla user-level commands in authoryear.bbx. I'd already sort of done that in the dev branch by checking for labelyear first but I think you're right, we'll stop using the user-level macros and so we don't have to worry about them. Is it clear to you what to do with this part now?

mergedate solution is exactly what I was thinking. I'll make biber deliver datelabelsource which will give the prefix of the field selected by \DeclareLabeldate. Now I think of it, I'm surprised this hasn't come up before as biblatex had no way of knowing which field was selected for the old \DeclareLabelyear either and it seems like useful information.

Now I think we're getting somewhere ... this package is becoming a beast.

[aboruvka]

Yes, it is clear. I can handle all the necessary sty and bbx changes sometime this weekend or (if later) whenever you get around to adding that new field.

[plk]

Should be done in biblatex 2.8 dev (had to bump the .bbl version string and reset the new field when necessary) and biber 1.8 dev. You will now see \field{datelabelsource} which can be blank in case DATE was selected so that you can use the value directly as the prefix.

\DeclareLabeldate can also choose non date fields (in which case the name of the field is in \field{datelabelsource}) or literal strings (in which case this new field isn't present at all). So, if \iffieldundef{datelabelsource} is true, there is no labeldate option or it's a literal string. If \iffieldundef{<value of datelabelsource>} is true, then it's a prefix. If \iffieldundef{<value of datelabelsource>} is false, then it's a non-date field.

[aboruvka]

Something seems wrong with the biber binary (Linux 64bit). I get the error:

ERROR - Error loading data source package 'Biber::Output::bbl': Can't locate Biber/Output/bbl.pm
in @INC (@INC contains: /tmp/par-616a626f7275766b/cache-fb6c109db7e4737524214ed14815b20b232c4b07/
inc/lib/tmp/par-616a626f7275766b/cache-fb6c109db7e4737524214ed14815b20b232c4b07/inc
CODE(0x1ac0d28) CODE(0x1ac1280)) at (eval 132) line 2.

I haven't fully decided on changes to mergedate, so no rush on getting this fixed.

[plk]

Ah, sorry. Should be ok now - I uploaded fixed versions for all platforms.

[aboruvka]

I forgot about two pre 2.6 bibtex cases: (1) labelyear is available and merged with day and month and (2) date is missing and some fallback is used for labelyear. The original mergedate drew only from date (hence the name merge date), so it's more complicated to get a sensible solution between backends. I'll have to consider this more.

[plk]

Any luck with this? I'm wondering about 2.8/1.8 release schedule as there have been some needed changes in biber libraries to comply with licensing and it would be nice to release 1.8 soonish ...

[aboruvka]

Yes. I'll push the code in the next day or so. I'm reverting to PL's definition of mergedate - merging only date elements with the date label, and not urldate or origdate. If you can point me to the feature request for the fallback month/days, I can post some code to handle that. I am thinking the overwhelming majority will either want no merging (via year-only labels) or merging only with date.

[plk]

Ok, great. I can't seem to find that request at the moment - I think it was on TSE ...

[plk]

@aboruvka - I lost track a bit - are we finished with this issue? I was thinking about 2.8 at some point not too distant.

[aboruvka]

I think so. Again I've restored mergedate settings to merge only date and not other date fields. By default merging is overrided by the datelabel = year setting. I avoided the yearonly name for the setting as the label may consist of year+extrayear.

I think it is safe to assume that the number of users wanting to merge other dates is very low. In any case such labels shouldn't be encouraged as they print date labels without any qualifier (e.g. urldate without urlseen string), which can be misinterpreted as publication dates. If merging is requested despite this, we can get the desired result with style changes.

[plk]

Are the docs up to date with the new datelabel setting and should we document datelabelsource?

[aboruvka]

The first is done from what I recall. The new field needs documenting. I can push changes unless you'd prefer to make them.

[plk]

I've updated the docs and so we'll close this for now.