{{ message }}

# Circa dates, circa date ranges, and question marked dates. Plus Eras.#427

Closed
opened this issue May 22, 2016 · 199 comments
Closed

# Circa dates, circa date ranges, and question marked dates. Plus Eras.#427

opened this issue May 22, 2016 · 199 comments
Assignees
Labels

I request support for:

• Circa dates, e.g. origdate={c 0125};
• Circa date ranges, e.g. origdate={c 1487/1490}; and
• Question marked dates, e.g. origdate={1750 ?}.

It would be desirable for these kinds of values to be permissible in all date fields. I use origdate as the more likely example. There might be reasons for choosing different symbols for these kind of dates, to make parsing easier. There might be reasons for disallowing spaces.

edit:
This issue thread also combines issue Before the common era (BCE/BC) and common era (CE/AD) date support. #422
/edit

## Kinds

When writing a scholarly piece there are several kinds of date ambiguities and uncertainties, these are listed below.

(Part of the power of Biblatex is in providing support for many and any type of style guide. But in the cases below I sometimes borrow from the ...

University of Chicago. 2010. The Chicago Manual of Style. 16th ed. Chicago:
University of Chicago. http://www.chicagomanualofstyle.org/16/contents.html.

... because it sheds some light on these issues. I could have chosen another style guide.)

1. Circa dates. Where the scholarship is only able to fix a date approximately. Generally this is beyond the precision of a year, as in "c. 125 CE" (rather than at the precision of a day: we rarely see, in publishing, something like "c. 0125-02-20").

ca. or c.

circa, about, approximately (ca. preferred for greater clarity)

(University of Chicago 2010, under "10.43 Scholarly abbreviations", http://www.chicagomanualofstyle.org/16/ch10/ch10_sec043.html)

// These are my examples (derived but not quoted from (University of Chicago 2010))
(Epictetus ca. 125 CE)
(Epictetus c. 125 CE)

2. Circa date ranges.

Citation: (da Vinci c. 1487–1490)

Reference Entry:
Da Vinci, Leonardo. c. 1487–1490. Codex Trivulzianus.

3. No dates.

"When the publication date of a printed work cannot be ascertained, the abbreviation n.d."

Boston, n.d.


(University of Chicago 2010, under "14.152 'No date'", http://www.chicagomanualofstyle.org/16/ch14/ch14_sec152.html)

4. Question marked dates.

A guessed-at date may either be substituted (in brackets) or added.
Edinburgh, [1750?] or Edinburgh, n.d., ca. 1750

(University of Chicago 2010, under "14.152 'No date'", http://www.chicagomanualofstyle.org/16/ch14/ch14_sec152.html)

5. Ambiguities over which known date is relevant. For example we might have the following reference entry:

Hume, David. 1751. “An Enquiry Concerning the Principles of Morals.”
In Enquiries Concerning Human Understanding and Concerning the Principles of Morals, 3rd ed., edited by L. A. Selby-Bigge and P. H. Nidditch. New York: Oxford University Press, 1975-06-12. isbn: 978-0-19-824536-0.

... but there is ambiguity around whether 1751 is the relevant original date, given ...

Selby-Bigge and Nidditch’s 1975 edition is based off a collection of Hume’s
essays posthumously published in 1777.

We could have chosen 1777 as the original date. But, in the case, we have reasons for choosing one date (1751) over another (1777). So in the reference entry we can add an annotation that explains all this. The annotation thereby handles the ambiguity ...

Selby-Bigge and Nidditch’s 1975 edition is based off a collection of Hume’s
essays posthumously published in 1777. However, Hume’s “An Enquiry Concerning the
Principles of Morals” was first published in 1751, and that's the date we use here.

## Feature requests for Biblatex

1. No dates; and
1. Ambiguities over which known date is relevant.

Biblatex also provides for date ranges.

So I request the additional functionality for:

1. Circa dates, perhaps input as in something like origdate={c 0125};
1. Circa date ranges, perhaps input as in something like origdate={c 1487/1490}; and
1. Question marked dates, perhaps input as in something like origdate={1750 ?}.

## Other considerations.

Often enough there might be no semantic difference between a circa date and a question marked date. Both can be used to express a uncertainty about a date. It's rare to come across a questioned marked date, relative to a circa date. So it might be tempting to ignore question marked dates with the rule: "If you are uncertain about a date just designate it as a circa date".

However, there probably are going to be contexts, albeit rare, in which an author does want to maintain a semantic difference. E.g. For dates they are personally uncertain about, the author might tag with a question mark. For a date that the author knows a community of scholars has established as having a lack of precision, the author might tag with a circa.

On the issue of whether to support output formats "ca." or "c." as the abbreviation for circa, I'm undecided. Personally I can generally mostly recall seeing c. 1815 and probably prefer this look, but the Chicago Manual of Style promotes 'ca.'. Perhaps both possibilities need to be supported for style authors who, in turn, provide options for users (with relevant defaults for a chosen style).

mentioned this issue May 22, 2016

### plk commented May 28, 2016

 Please try biblatex 3.5/biber 2.6, both on SF in their respective development folders. All of these requirements are now implemented. "circa" is a localisation string which and there are tests for authors to determine if a data came with a circa or uncertainy marker. See the PDF manual, section 2.3.8.

### njbart commented May 29, 2016

 The new date specifications are great, but I am deeply worried about one aspect: While it’s clear that -03430203 should be parsed as 344-02-03 BCE, it’s extremely confusing to find 343-02-03BC being parsed as 344-02-03 BCE. 343-02-03BC should never be parsed in any other way than 343-02-03 BCE. Please reconsider.

### plk commented May 29, 2016

 That looks like a date parsing bug, I'll look into it.

### plk commented May 29, 2016

 Actually, this is just a typo in the documentation ...

### njbart commented May 29, 2016

 Indeed, my comment was based on the documentation only. Thank you for looking into this.

### njbart commented May 29, 2016

 https://github.com/plk/biblatex/blob/dev/doc/latex/biblatex/biblatex.tex#L1672: circa. 1723 BC& c. 1723-02 BC Typo?

### plk commented May 29, 2016

 PDF looks ok - that's just a table column sep with a space missing before it - shouldn't make any difference, just looks a little odd in the source. I will correct it anyway.

### njbart commented May 29, 2016

 No, I mean, shouldn’t this be circa. 1723-02 BC& c. 1723-02 BC?

 Ah, no, the "?" is only for uncertainy, not circa. To get something like "c. 1723-02 BC?", you would have to have had both circa and uncertainty markers "circa. 1723-02 BC?". Of course, this is style dependant. A style could choose to put an uncertainty marker in the output if it only found a circa marker but they are semantically separate in case one doesn't want to do this.

 Sorry, again: isn’t a -02 missing in the first column? I.e., circa. 1723-02 BC & c. 1723-02 BC rather than circa. 1723 BC & c. 1723-02 BC ?

### plk commented May 29, 2016

 Ah, sorry, in the middle of something else and not really reading properly. You are quite right. Corrected in git in a few minutes.

pushed a commit that referenced this issue May 29, 2016
 Typo as per #427 
 90e06f1 

 Come to think of it, it seems you just implemented, more or less straightforwardly, the OP’s suggestions. I’d like to propose using a different format that’s much closer to a generally accepted standard instead, i.e., “Extended Date/Time Format (EDTF) 1.0”, an extension of ISO8601 (https://www.loc.gov/standards/datetime/pre-submission.html); or more specifically, its Levels 0 and 1 – rather than contributing once more to the proliferation of mutually incompatible date formats. All of what has just been introduced to biblatex can be expressed by EDTF just as well. Some differences: 8601 extended form only, i.e. with hyphens year must be four digits year may be positive, negative, or year zero, i.e., assumes astronomical numbering no CE/BCE, only -0343 rather than 344 BCE uncertain/approximate: 1984?~ rather than ca. 1984? However, if there is a general will to keep these new private biblatex extensions, fine (though I personally wouldn’t do so), but at least it would be good if biblatex would understand the EDTF uncertain/approximate formats like 1984?~, too.

### JohnLukeBentley commented May 29, 2016

 Philip, awesome. I have 96-dates.tex working. I'm now commenting on both Circa and Era issues here, having closed Before the common era (BCE/BC) and common era (CE/AD) date support. #422 for the sake of consolidating discussion. I haven't yet resolved why my package manager returns version 3.4 for the biblatex package (when it was the 3.5 package I downloaded). Indeed I'll probably, as suggested, post on Tex Stack Exchange to get this resolved. And yes it feels like I may have copied the package files to the wrong place (or failed to delete old packages). However since I have 96-dates.tex working I'll ignore the discrepancy for now. Another part of my problem, now fixed, was an misconfiguration (highly particular to my setup) of my output directories in TeXStudio and using the wrong latex drivers. Thanks to your tip off I'm now using xelatex and biber. So the pdf I compile (with xelatex and biber) from 96-dates.tex is identical to your enclosed 96-dates.pdf. Broadly I think you've taken my initial suggestions and molded them into a robust and document-author accommodating design. I like that, for inputs, you've been permissive. Namely, optional spaces, optional dot after circa markers, all three kinds of circa markers ('c', 'ca', and 'circa'), all four era markers ('BC', 'BCE', 'AD', 'CE'). @nickbart1980 good catch on the missing -02 in the documentation. And Nick I do think you raise a worthy counterpoint, a case to be made for not being so permissive and to more tightly force users to input dates that conform to ISO 8601. That's a useful link to "Extended Date/Time Format (EDTF) 1.0". In general I too prefer a convergence on one standard rather than a proliferation of standards. I'm going to take some time (a day or three) to think about a few things before disagreeing or agreeing. I'll also use a modified 96-dates.tex to see if I can break Philip's design/implementation with edge cases. You, Nick, wrote (looking at Page 73 of the docs) While it’s clear that -03430203 should be parsed as 344-02-03 BCE, it’s extremely confusing to find 343-02-03BC being parsed as 344-02-03 BCE. 343-02-03BC should never be parsed in any other way than 343-02-03 BCE. Philip thought this might be parsing bug. I take it, you Nick, where referencing the issue of year conversion, whether you minus one before taking the absolute. It looks to me this was a documentation bug. Taking 96-dates.tex (which uses \usepackage[style=authoryear,alldates=short,backend=biber]{biblatex}) I added 343-02-03BC and this parses to 02/03/343BCE. Ignoring the issue of / and year-month-day sequencing, that's right, and in accord with what you suggest: the year string is kept at 343 and not changed to 344. Philip, having done no style authoring before I'm beginning to appreciate the flexibility on that side of things. For example I see in 96-dates.tex how easy it is to take \ifdateera{bce}{\bibstring{beforecommonera}}{}  ... which produces something like "878BCE" and change it to .. \ifdateera{bce}{{ }\bibstring{beforecommonera}}{}  ... to get "878 BCE". Would I be right in thinking that, with what you've currently implemented, it would be fairly easy for a style author to create a rule that said "For dates less than 500 return an era suffix; otherwise return no suffix" (for indeed that sort of rule seems like it might be a common want)? E.g. to output ... 1066 877 400 CE 380 BCE  ? One trivial suggestion with respect to your Pdf documentation: It might help if you number your bookmarks, to make it easier to jump to referenced sections (as when referenced here on github). Passing the option bookmarksnumbered to the hyperref package does this. Nick I think you'll agree that whatever ought be, and will be, the final form of all this, Philip has come with a superb first go, in short time. Bloody marvelous effort Philip!

### plk commented May 29, 2016

 Please pull 3.5/2.6 again. This is all now integrated into the standard styles with options (dateera, dateuncertain, datecirca) to control what is output along with formatting commands and context-aware delimiters. By default, nothing new is output to maintain backwards compatibility. The 96-dates.tex example file is updated to use these options and contains some commented examples to demonstrate things like your "<500" only scenario. @nickbart1980 - I do prefer to keep things clean but the problem with biblatex is always that people are using more and more various methods for automating collection of bibliographic data and we have no control over the format and have to be quite flexible in what we accept. I went by ISO8601v2004 on the whole but allowed some more flexibility in the parsing. I have added support for the EDTF circa marker as requested. If in this UAT phase for 3.5 there is an outcry for reduction of date formats, it's relatively easy to do.

changed the title Circa dates, circa date ranges, and question marked dates. Circa dates, circa date ranges, and question marked dates. Plus Eras. May 29, 2016

### JohnLukeBentley commented Jun 2, 2016

 Philip and Nick. I've pulled the latest version (not long after Philips last post) and am working through various standards issues. I'll need some more time on this but believe I'll be able to provide useful feedback when done.

## Which input format(s)?

Before doing anything else it might be wise to get conceptually clearer on the date/time formats we are aiming at (I use the royal "we" given you, Philip, are the one doing the work and, appropriately and therefore, making the final calls on this). That is, as part of evaluating @nickbart1980's worthy suggestion to be less permissive and follow existing standards.

I take it this is principally an issue of the input format. That is, that none of us have a problem with biblatex supporting all sorts of wild date/time formats when outputted, which will include all of, or many of, the language localisations and style guides (Chicago, APA, etc.). Notwithstanding we'll want a few sensible default and standard output formats.

Our chief question for the moment is therefore: Which input format(s)?

I've now skimmed:

## The current (as under development) input format.

So at the moment we have Philip's design/implementation: derived from my initial suggestions, ISO8601:2004, and nickbart1980's (well suggested) additional approximately/circa suffix symbol ~ (as found in EDTF).

So looking at this current specification, as exemplified in "Table 4: Enhanced Date Specifications", page 37, biblatex.pdf I think we'd do well to conceptually divide this into (adding some examples of my own):

• Strict. Entailing the ISO8601:2004 conforming parts. E.g.

-0877/-0866
-034302
-0343-02
-0343-02-03
-03430203

• Colloquial. Entailing the Era suffixes and BCE Years that are nominally one less, or "more" depending on how you want to speak about it, (e.g the "280" in "280 BCE") than their ISO equivalent (e.g. the "279" in "-0279").

  877 BCE
124BC/122BC
2004 CE
343-02-03BC

• Additional qualifying symbols. Entailing the uncertainty suffix ? and the approximate/circa prefixes (circa, ca, c) and suffix (~). With optional periods . for the prefixes.

Spaces are optional.

So at the moment an input date is required to be formatted as either:

• A. Strictly conforming plus optional additional qualifying symbols; e.g.

  -876
1723
ca. 1723
circa 1723
1723~
1723?


... or ...

• B. Colloquially conforming plus optional additional qualifying symbols.

  877 BCE
ca. 1723 CE
circa 1723 CE
circa. 1723-02 BC
1723~ CE
1723? BC


Sliced and diced this way we might be in a better position to argue over what the input format(s) should be.

Additionally I think this conceptualisation, or something like it, would assist users in understand what's going on.

Recommendation: In the documentation include the conceptual scheme (or something like it) that distiguishes between: strict; colloquial and additional qualifying symbols.

## Allow "+" sign?

ISO8601:2004, under "3.4.2 Characters used in place of digits or signs".

[±] represents a plus sign [+] if in combination with the following element a positive value or zero needs to be represented (in this case, unless explicitly stated otherwise, the plus sign shall not be omitted), or a minus sign [−] if in combination with the following element a negative value needs to be
represented. ...

4.1.3.3 Expanded representations

If, by agreement, expanded representations are used, the formats shall be as specified below. The
interchange parties shall agree the additional number of digits in the time element year. In the examples below it has been agreed to expand the time element year with two digits.

A specific day
Basic format: ±YYYYYMMDD
Extended format: ±YYYYY-MM-DD

So the basic form, if a sign [±] is used, is:

+0001
+0000
-0001

But for positive dates and zero, ISO8601:2004 also allows for omitting the sign:

4.1.2.2 Complete representations ...

Basic format: YYYYMMDD ...
Extended format: YYYY-MM-DD ...

So the following is permissible:

0001
0000
-0001

Neither format, with or without plus signs, has any sorting advantage. If a date list is represented as a string and includes negative and positive years, with or without a plus sign, there is no possible ordering that begins with the earlier years and ends with the later years.

So the only reason left to support plus signs is:

• Because ISO8601:2004 supports it; and
• In some contexts it might help with the visuals of lining up dates in a column.

EDTF does not allow for "+YYYY".

Recommendation:

• (My preference, see below) If we want to support ISO8601:2004 we'd want to allow a plus sign "+" for positive years and zero; in addition to allowing positive years and zero without a sign.
• If we want to support, rather, EDTF we need to disallow a plus sign "+" for positive years and zero.

## How many digits for years?

Part of the motivation for keeping all years to 4 digits (or more) in a standard like ISO8601:2004 is sorting and to remove ambiguity. I suggest that kind of motivation ought apply even in the colloquial input format.

On ambiguity consider 343-02 BC. If you are allowing 3 digit years, are you also allowing two and 1 digit years?

Consider 11-02 BC. Is that February of 11 BC; or the second day of November in some unspecified BC year? It's not intuitively clear just from reading it.

Also under ISO8601:2004 three digits are used to represent the ordinal day in a year. E.g. 032 will represent the 1st of February. 032 BC could mean the 1st of February in 1 BC; rather than the year 32 BC. It is better, therefore, to avoid 3 digit dates even in the colloquial input format.

Recommendation: All years, whether under the strict or colloquial input format, be 4 digits. (There'd be no problem supporting a year with less than 4 digits in an output format).

Assuming, that is, that 3 digit years aren't already supported for positive years in production biblatex. If they are I'd suggest deprecating them (allow them through with a WARN message).

In this respect I'm agreeing with Nick here.

## Allow time?

Increasingly stuff (articles, books, etc.) gets published on the internet. In this context increasingly the date of publication is too imprecise. We want, rather, the precision of time and date. Chiefly because the time and date serves as a version number.

Recommendation: Support times, with dates. Support optional time zone information. (Ramification: Perhaps, in that case, we'd need a rule: if there is a time, it must come with a date).

## Allow space between date and time?

A space is more human readable.

ISO8601:2004 allows it ...

By mutual agreement of the partners in information interchange, the character [T] may be omitted in
applications where there is no risk of confusing a date and time of day representation with others defined in this
International Standard. (Under "4.3 Date and time of day > 4.3.2 Complete representations")

Recommendation: Allow for space between date and time, as well as the character "T".

## Which strict format?

### ISO8601:2004 and EDTF

Nick is correct that the colloquial format, for inputting, could be removed without losing expressive power. But before addressing that, let's think about which strict format we want.

The candidates seem to be:

• ISO8601:2004 (the current format); or
• EDTF 1.0 2012-01-13 (from now on cited as "EDTF"), at level 0;

Note that under my way of slicing and dicing it, the EDTF approximate suffix (~) is available as a matter of being a additional and optional "qualifying symbol". So agreeing that ISO8601:2004 ought be the strict format doesn't preclude borrowing from EDTF for "qualifying symbols".

But here I want to mention a few things about ISO8601:2004, EDTF, and the relationship between the two.

Firstly, EDTF is accessible from an intro page at https://www.loc.gov/standards/datetime/ which says

This website describes the current effort to develop a reasonably comprehensive date/time definition for the bibliographic community, as well as other interested communities, and submitting it for standardization or some other mode of formalization, for example a W3C note or an amendment to ISO 8601.

That EDTF was worked out after ISO 8601:2004 and, especially, that it was formulated specifically for "the bibliographic community" makes it impressively relevant to our current biblatex issue. It makes EDTF worth some serious consideration here.

On the other hand EDTF is merely a draft and in a state of flux. So I wouldn't necessarily favour it merely because it is a standard. I'd suggest, the best course is to conform to it or borrow from it if we find there's good reason to do so in virtue of our particular context: the use of dates (and possibly times) in biblatex.

Secondly, EDTF is inconsistent from ISO 8601:2004 in some important respects, even though it derives from it. As EDTF mentions

8601 ... describes a large number of date/time formats, and in many cases provides multiple options for a given format. Thus a second aim of this specification is to restrict the supported formats to a smaller set. This specification therefore profiles 8601 in the sense that it discards many redundant or less-useful features.

So the datetime format (ingoring the date only format for the moment) is more restricted than in ISO 8601:2004. Namely in EDTF (at Level 0)

time string MUST be composed according to one of three representations as illustrated in the following three examples:

2001-02-03T09:30:01
2004-01-01T10:10:10Z
2004-01-01T10:10:10+05:00

Note: 'T' separating date and time must be upper case.

The date/time string MUST use 8601 extended form, i.e. date with hyphen, time with colon. Zone-offset may be omitted or included. 8601 extended format time zone designation consists of either a 'Z' to indicate UTC, or a '+' or '-' to indicate "ahead of UTC" or "behind UTC", followed by a 2-digit hour, followed optionally by a colon and the 2-digit minutes.

The time part is also optional under EDTF level 0 (as, of course, for ISO 8601:2004).

Under EDTF level 0, therefore, a date like 20010203 is not permitted. Under ISO8601:2004 it is permitted (and is currently supported by Philip's implementation). That counts in favour of EDTF in my view.

However Under EDTF level 0, a space between the date and time is not permitted. That fatally sinks that standard in my view.

Recommendation: For the strict format us ISO8601:2004, not EDTF level 0.

## Should there be a colloquial input format?

Recall the colloquial formatting: Entailing the Era suffixes and BCE Years that are nominally one less, or "more" depending on how you want to speak about it, (e.g. the "280" in "280 BCE") than their ISO equivalent (e.g. the "279" in "-0279").

  877 BCE
124BC/122BC
2004 CE
343-02-03BC


My motivations in suggesting this input format were twofold:

1. To supporting a colloquial output format where some dates in a list have the era prefix. E.g.

1066
0877
0402 CE
0382 BCE

2. To preserve *.bib files as being readable by non (computer) technical folk. That is, to allow for something like date = {0380 BCE} rather than force everyone to recognize date = {-0379}

The second motivation is the chief reason for the recommendation. Under ISO8601:2004 dates greater than zero become immediately easy to interpret. If you weren't familiar with the standard, you could guess that 1505-05-10 probably means YYYY-MM-DD.

However, dates less than zero are unwieldy even when you are familiar with the standard. What does -0379 mean? You have to recall that Dionysius Exiguus, when creating the Anno Domini system in 0525, afforded no room for a zero year (it goes 2 BC, 1 BC, 1 AD, 2 AD). You therefore have to mentally subtract a year, take the absolute, in order to convert to the colloquial (and traditional) 0380 BCE. In 6 months time I'm likely to forget whether you add or take away from -0379 to make the conversion.

It is right that ISO8601/EDTF express years less than zero as negatives like -0379, and take into account a year zero. For that solves many, even if not all, sorting issues. But, alas, it is nevertheless jarring against the traditional BCE/BC dating scheme.

So supporting both the strict ISO8601/EDTF (-0379) and colloquial (0380 BCE or 0380 BC) is a good move, to allow for those folk that want a strict format and those folks that prefer something more human readable.

Recommendation: Keep the colloquial input format, in addition to the strict format; but have 4 digit years under the colloquial format (as previously covered).

## How about a biber/biblatex option for outputing the era names below X?

Philip, your commented out code in 96-dates.tex for displaying the era name for dates less than 500 did not work. However, you thereby enabled me to modify it ...

\ifdateera{bce}{
\ifnumcomp{\thefield{#1}}{<}{500}
}{
% E.g. Is year between 1 and 500.
}


... With the addition of utility code from Peter Grill, "xstring test for numbers within a range" http://tex.stackexchange.com/a/159865/105123

My result was as desired ...

Era format restricted to date range
labeldate = 1066
date = 1066
origdate = 877
eventdate = 402 CE
urldate = 383 BCE


So I see that this works well enough at the style author level. But I'd suggest this would be very handy as an option (in addition to datecirca, dateuncertain etc.).

Recommendation: Add "show era name less than X" functionality through an option. Either by:

• Adding another option (e.g.) dateerashowbelow= positive integer | all. (default = 0); or
• Adding values to the current option dateera = secularX, christianX (where x is: a positive integer; all; or missing). E.g. secular500 displays the era name below 500; secular and secular0 displays the era name below 0; christianall displays the era name for all dates.

## Summary of Recommendations

Documentation

Recommendation: In the documentation include the conceptual scheme (or something like it) that distiguishes between: strict; colloquial and additional qualifying symbols.

Allow "+" sign?

Recommendation:

• (Recommended option) If we want to support ISO8601:2004 we'd want to allow a plus sign "+" for positive years and zero; in addition to allowing positive years and zero without a sign.
• If we want to support, rather, EDTF we need to disallow a plus sign "+" for positive years and zero.

How many digits for years?

Recommendation: All years, whether under the strict or colloquial input format, be 4 digits. (There'd be no problem supporting a year with less than 4 digits in an output format).
Assuming, that is, that 3 digit years aren't already supported for positive years in production biblatex. If they are I'd suggest deprecating them (allow them through with a WARN message).

Allow time?

Recommendation: Support times, with dates. Support optional time zone information. (Ramification: Perhaps, in that case, we'd need a rule: if there is a time, it must come with a date).

Allow space between date and time?

Recommendation: Allow for space between date and time, as well as the character "T".

Which strict format?

Recommendation: For the strict format us ISO8601:2004, not EDTF level 0.

(But, again borrowing, rather than conforming to, EDTF is fine. It was a good idea to add support for ~, as Nick suggested).

Should there be a colloquial input format?

Recommendation: Keep the colloquial input format, in addition to the strict format; but have 4 digit years under the colloquial format (as previously covered).

How about a biber/biblatex option for outputing the era names below X?

Recommendation: Add "show era name less than X" functionality through an option. Either by:

• Adding another option (e.g.) dateerashowbelow= positive integer | all. (default = 0); or
• Adding values to the current option dateera = secularX, christianX (where x is: a positive integer; all; or missing). E.g. secular500 displays the era name below 500; secular and secular0 displays the era name below 0; christianall displays the era name for all dates.

in addition to allowing positive years and zero without a sign.

### plk commented Jun 2, 2016

 The first thing to note is that sorting is not relevant here because the sorting system takes care of normalising dateparts for sorting. This means that the 3 vs 4 digit year issue is not really an issue. Times - hmm. It is easy to support the input formats for this but the scaffolding internally to support times and time parts would be quite significant, akin to that needed for dates. I've had no request for this in years and no questions about this on TSE so I'm not really convinced that this is really needed by anyone. I haven't seen any style that requires time of access for URLs etc. Also with the "era less than" thing - is there a style that actually needs this? The general policy is not to implement in core things which are fringe style requirements since this can be done easily in a style which requires it.

Thanks Philip.

## Number of digits in a year and sorting

Biblatex does indeed handle sorting properly, in virtue of date parts, but, as you pointed out before, these dates import from, and export to, all sorts of programs. If an external program, some reference management software chiefly, treats a year value as a string then sorting years, some of which will be 3 digits, will come out as:

125
1300
200

But as I say, there is no possible sorting, even if all the years are expressed with 4 digits and are treated as strings, that properly orders dates which range over negative and positive years.

And software shouldn't be treating dates, or date parts, as strings.

So I agree that sorting is a less significant reason for enforcing 4 digit years.

The more important reasons are, firstly, that it aids looking at dates in a column. An example to hand is I'm using Zotero Reference Management Software with the addin "Zotero Better Bib(La)Tex" in order to export custom fields to biblatex. The addin stuffs fields as a delimited string in Zotero's native "Extra" field. In that field I might have these three separate entries:

biblatex[origdate=0125,shorthand=MoE]
biblatex[origdate=0200]
biblatex[origdate=1300]

And when I sort on my entries by the "Extra" column, visually scanning down that column is aided by having those year values line up vertically.

Secondly, and most importantly, are the ambiguities in interpretation that I mentioned.

For my own purposes a lack of enforcement of 4 digit years in biblatex is less of a problem. Since you allow 4 digit years (although I've yet to test something like "0025") , I can just enforce this workflow for myself.

But I make my argument trying to think of future users who might inadvertently create problem for themselves that could otherwise be prevented by enforcing this discipline on them from the start.

## Times

In terms of the need, I'll make three arguments.

Indulge me pressing the prior argument first up. The argument is that the need may become increasing, as internet publishing matures. Specifically there'll be some kinds of documents that will be rapidly changing and it becomes important when citing such documents to identify the right version. Think of a newspaper article that might get updated 3 or 4 times over several days as new facts come to light. You might wonder why an author doesn't take into account some particular fact in the article. If you follow their citation, with a datetime stamp, you'll be enabled to see they were referencing an earlier version.

In addition to the utility for version monitoring the one document sometimes it's significant compare datetimes between documents. I'll use Zotero and newspapers again as an example. If I surf to the newspaper article http://www.abc.net.au/news/2016-06-03/weather-warning-issued-for-nsw/7473294 and use the Zotero browser plugin to "Save to Zotero using embedded metadata" then the Date is captured in Zotero with a datetime string of 2016-06-03T07:28:33+1000.

I'm not sure which of the webpage metadate fields it comes from but it could be coming from a field like ...

<meta name="DC.date" scheme="DCTERMS.W3CDTF" content="2016-06-03T07:28:33+1000"/>


But all that time info will be lost when exporting to biblatex (unimportant for a local weather event but potentially significant for an international event like an unfolding war, toppling of a leader, etc. when checking the up-to-dateness of different news sources).

Thirdly, that the request for this has been rare might more a product of people being used to being unable to exercise a power (storing times with their citation entries) and therefore dropping the desire for it. If you enable the power folk might come to learn how it is useful. Quite a general phenomenon I'd suggest.

But yes, I suspected it might be quite a large body of effort to implement times. For that reason alone how about we drop it as a present requirement? I could then raise it in another ticket, at some future time. It's personally less important than other features of date support (most of which you've already implemented).

## Era less than, as a biblatex option.

I'm not very well versed in style guides. I've only recently subscribed to Chicago and there doesn't appear to be any specification with respect to this.

My specific needs comes from the context of publishing Philosophy academic papers. In this context, frequently enough, the history of an issue will be traversed from ancients to contemporaries. In the case you'll end up with a set of dates like:

1066
0877
0402 CE
0382 BCE

Indulge me repeating a previous argument. In this context, for positive or negative dates close to zero that are expressed in era terms, when an author cites "0382 BCE" the date is unambiguous. When an author cites "0402", without the era term, as a reader you wonder whether the author truly means it to be a positive ("CE") year, or it was a negative ("BCE") year and they accidentally omitted "BCE". If the author writes "0402 CE" then the reader can be more confident the author intends it.

As positive dates move further away from zero a reader can be more confident the year with out an era suffix, is as intended. The context of the paper is much more likely to make dates cited as 1066, 1266, 1786, 2012, etc, unambiguously positive ("CE") years.

Fringe need or not, it's a feature, era-less-than as a biblatex option, that I'd personally find very useful. It would make me personally very happy if you implemented it (and it was not too much work on your side). That would help keep my documents (or custom styles) relatively lightweight.

Alternatively, we could settle on making the style-level example in 96-dates.tex clean and robust.

In any case, all that you've so far done is awesome.

 I haven't seen any style that requires time of access for URLs etc. Well, the Chicago Manual of Style, 16e, 14.246 “Citations of blog entries”, does list one example: AC, July 1, 2008 (10:18 a.m.), comment on Rhian Ellis, “Squatters’ Rights,” Ward Six (blog), June 30, 2008, http://wardsix.blogspot.com/2008/06/squatters-rights.html. I’d agree there seems to be no widespread demand for including time yet (not on the Zotero and CSL forums either), but at the very least it would be useful, for now, if biblatex could parse date fields that include a time without complaining.

mentioned this issue Jun 6, 2016

### simifilm commented Jun 7, 2016

 Just to make sure – is it correct that the cite commands in the standard styles do not (yet) take account of this? See this MWE % % This file demonstrates various date formats and tests which apply to them % for output % \documentclass[a4paper]{article} \usepackage{fontspec} \usepackage[american]{babel} \usepackage{csquotes} \usepackage{filecontents} \begin{filecontents}{\jobname.bib} @book{buch, author= {Wurm, Tom}, title = {Das Buch}, date = {1982/1988}, location = {Die Stadt}, publisher = {Der Verlag}} @book{buch2, author= {Wurm, Tom}, title = {Das Tuch}, date = {-1992/-1988}, location = {Die Stadt}, publisher = {Der Verlag}} \end{filecontents} \usepackage[style=authoryear,% alldates=short,% dateera=secular,% dateuncertain=true,% datecirca=true,% backend=biber]{biblatex} \addbibresource{\jobname.bib} \begin{document} \cite{buch,buch2} \printbibliography \end{document}  The negative dates are printed in the bibliography but are ignored in the in-text citations.

### plk commented Jun 7, 2016

 That's true, I haven't looked at citations yet.

### simifilm commented Jun 7, 2016

 I'm probably missing something here, but AFAICS it is not possible to output negative values as such, i.e. print origdate = {-331} simply as -331. And is it really intended that negative values are printed as positiv when dateera is not set?

### plk commented Jun 7, 2016

 The style can format negative dates however it wants but the default styles will use the dateera information with the relevant bibstring. The other question is tricky. dateera just adds era information to the .bbl and then styles can use it and so any style which handles negative dates should always use dateera and do something sensible on output I suppose.

### JohnLukeBentley commented Jun 7, 2016

 Allowing for the output of negative years as negative years, origdate = {-331} simply as -331 (or as I've been suggesting -0331), I think ought be allowable in default styles through options. That'd otherwise break, in the default styles, whatever "strict" format (ISO8601:2004 V EDTF 1.0) was chosen. I hadn't previously mentioned this issue, with some others, in virtue of the state of flux of the broad target date format standards: ISO86001; EDTF 1.0; "strict"; "colloquial". For example, if EDTF 1.0 was to be chosen as the strict format then settings like alldates=edtf1 might need to be promoted over a deprecated alldates=iso8601. So sorting that out those overarching standards issues first would ease Philips workload when it came to thinking about how to implement options. I have also been holding off commenting because I wanted to get do some testing around @nickbart1980's last issue: what happens when a date field with a datetime value is parsed (but haven't yet got around to this). Nick, it would be great to have your thoughts on each of my Recommendations (e.g. as listed under "Summary of Recommendations"). Even if, for example, that'll entail a reassertion of your promotion of EDTF. Philip may have already been privately persuaded on the issues I raised, for or against individual recommendations. Indeed Philip could be part way through implementing some of them. But it would be valuable to hear some other voices weigh in on this, especially any contrary voices. I have been supposing that Philip was holding off on further work, in order to afford more time for you, Nick, to make some further comment. So, simifilm, it is good of you to raise this detail, of formatting negative years. It helps ensure it's on the list as an issue. But there are many ways in which the current, under development, implementation can be made to break. And so sorting out what we want needs to have priority over how the current implementation happens to fail. So if you have any particular views on what ought be, as you play with the current development implementation or review this thread, that'd be great. I hope none of what I've written creates any sense of being rushed in anyone. There's nothing wrong with this project ticking over slowly (and necessarily and finally at Philip's discretion).

 I just spent quite some time till I understood that the \ifdateera tests are only available (or rather the data they need) when the dateera option is set. I am not really sure whether this is a good choice. In my understanding, dateera defines how negative values will be typeset and not whether this information is actually available. I also think that the manual is at least ambiguous here.

### plk commented Jun 7, 2016

 I think you are right, I will change this.

### JohnLukeBentley commented Jul 26, 2016

 Errors when using APA style. \documentclass{article} \usepackage[american]{babel} \usepackage{csquotes} \usepackage{filecontents} \begin{filecontents}{\jobname.bib} @article{chalmers_1995_facing, author = {Chalmers, David J.}, date = {1995}, title = {Facing up to the problem of consciousness}, pages = {200--19}, journaltitle = {Journal of Consciousness Studies}, number = {3}, timestamp = {2016-06-05T20:09:34Z}, url = {http://consc.net/papers/facing.html}, volume = {2} } \end{filecontents} \usepackage[ style=apa, alldates=ymd, backend=biber, ]{biblatex} \DeclareLanguageMapping{american}{american-apa} \addbibresource{\jobname.bib} \begin{document} \autocite{chalmers_1995_facing}\\ \printbibliography \end{document}  line 32: Undefined control sequence. \end : Overwriting file ./BiblatexApa-Mwe.bib'. : 'labeldate' option used to determine whether to provide label date fields and(biblatex) extrayear field is renamed to 'labeldateparts', setting this instead. This option is now used to set the format of the labeldate. : '\mkbibrangeapalong(extra)' date range macro in style is deprecated,(biblatex) please define '\mkdaterangeapalong(extra)' instead. : 'datelabel' option is deprecated, use 'labeldate' instead. : '\mkbibrangeapalong(extra)' date range macro in style is deprecated,(biblatex) please define '\mkdaterangeapalong(extra)' instead. : '\mkbibrangeapalong(extra)' date range macro in style is deprecated,(biblatex) please define '\mkdaterangeapalong(extra)' instead. line 30: Underfull \hbox (badness 10000) in paragraph

 Yes, the APA style is mine and I have a dev version of the APA style which works with 3.5/2.6 dev - not released yet ...

 Thanks. Yes I noticed APA was yours - that's convenient :) I'm in the process of getting clear on both the Chicago and APA style guides in terms of dates. To see how that might inform us about handling datetimes. That is, primarily with a view of what needs to be in the core, and how the core ought behave. Secondarily to see if the biblatex included styles could use some adjustment. Tertiarily to see if add on styles could use some adjustment. So feel free to delay your APA development. You might be able to leverage my analysis. Edit: I mean: you are probably across all those guides. But I need to catch up: and even then I might see that the biblatex core requires no adjustment.

### JohnLukeBentley commented Jul 30, 2016

 Philip, life has been getting in the way, but I'm still plugging away at this.

# The style guides on dates and datetimes

I've made a review of two style guides - the Chicago Manual of Style, 16th Ed. (Chicago) and the Publication Manual of the American Psychological Association, 6th Ed. (APA) - to see the various ways dates are, and ought be, formatted.

You (@plk) will have been through all that: so I'm mostly catching up.

However my hope is that the following issues it might serve as a suitable reminder and touchstone for any further biblatex date and datetime issues. I'm only picking out those date and datetime issues from the style guides that might be biblatex relevant, rather than mention everything the style guides has to say about dates (and datetimes).

So, a style author (whether of a style manual, a biblatex standard style, a biblatex add-in style, or a biblatex user overriding/customizing a style) has to decide on the following issues:

(In the following examples bold is added, italics are original.)

• Outputting date precision finer than year level. Whether to forbid it, permit, or mandate it; and whether to set that permission globally, on a type basis, or entry basis.

E.g. A decision might result in the following: a date expressed to month precision, for a journal published monthly Chicago 14.180, "Journal volume, issue, and date" :

• Kennett, Jeanette. "True and Proper Selves: Velleman on Love." Ethics 118 (January 2008): 213–27. doi:10.1086/523747.
• Contiguous date V date separated by other publication facts.

E.g. If choosing to separate a date by other publication facts we might end up with what Chicago does. Chicago 15.47, "Newspapers and magazines in reference lists":

• Date precision correspondence. That is, if relevant, an in-text to reference correspondence of the date precision.

E.g. When it doesn't correspond. Chicago-Style Citation Quick Guide, Author-Date, Ex "Article in a newspaper or popular magazine":

• Mendelsohn, Daniel. 2010. "But Enough about Me." New Yorker, January 25.

(Mendelsohn 2010, 68)

... That is, the date in the reference is precise to the day (2010-01-25); but the in-text citation is precise to the year (2010).

• If dates have corresponding precision, should the formatting correspond?

Although I can't find anything explicit the APA seems to encourage a possible scheme like:

E.g. Given APA, CH 7, Ex 11 Online newspaper article ...

• Brody, J. E. (2007, December 11). Mental reserves keep brains agile. The New York Times. Retrieved from http://www.nytimes.com

... the APA seems to encourage an in-text, inconsistent format, like (this is an example I derive from APA, not quote):

Lorem (Brody, The New York Times, December 11, 2007)

One could, instead, insist upon consistency like:

Lorem (Brody, The New York Times, 2007, December 11)

• Later versions of a work. Whether, firstly, to include a modern and original date. Secondly, if the two dates are included, which to make more prominent. Thirdly, if the two dates are included, how to present them in the reference and in-text citation.

E.g. One possible set of decisions could result in Chicago, CH 15.38, Reprint editions and modern editions - more than one date:

Austen, Jane. (1813) 2003. Pride and Prejudice. London: T. Egerton. Reprint, New York: Penguin

(Austen [1813] 2003)

• Electronic sources (and some other print sources). Datetimes, last updated, access date.

• Datetimes. Whether to include the time as well as the date (and, as of the dev version, we have a time facility in the biblatex core).

From Chicago-Style Citation Quick Guide, "Notes and Bibligraphy", "log entry or comment".

Jack, February 25, 2010 (7:03 p.m.), comment on Richard Posner, "Double Exports in Five Years?," The Becker-Posner Blog, February 21, 2010, http://uchicagolaw.typepad.com/beckerposner/2010/02/double-exports-in-five-years-posner.html.

(Ignore "February 21, 2010", it is ambiguous. It is meant to reference the main blog post, not an access date. I'd prepend a "main post" to remove the ambiguity. I've raised this issue on the Chicago forums. Chicago-Style Citation Quick Guide. Suggest correction to example).

• Last updated (aka "last modified", "revised", "last revision"). Whether to included it and how to related it to other dates.

The style guides are a bit nebulous on this, perhaps by necessity. But, for example, one could use the following crude algorithm:

• If sensible include both first posted and last updated datetime. Choose one of these dates to be more prominent.
• Otherwise select only one datetime available in the following priority order: last updated, first posted, accessed.
• Override the above if context demands it.
• Access date. (aka "retrival date", "retrived", "accessed", "visited"). Whether to include one.

• One author with many works in same year, where a date is more precise than a year. How shold this be formatted?

E.g. One possible set of choices are: include full datetime in both reference and in-tex citation; but keep the year alphabetic (a, b, etc.) - and append the alphabetic at the end of the entire date.

References:

• Barker, Anne (2016-06-06 18:20 +10:00 a). "Swiss voters say no to guaranteed ...
• --- (2016-07-18 20:26 +10:00 b). "Turkey divided between secular and ...

In-tex citations:
(Barker 2016-07-18 20:26 +10:00 b)
(Barker 2016-06-06 18:20 +10:00 a)

All that's a summary of what I've written about, and quoted from, Chicago and APA. I have about 4,000 more words of detail (that's partly what's taken all this time). If anyone wants that more detailed coverage, or parts of it, let me know and I'd be happy to post it. Perhaps some of that detail will shake out in further discussion.

If this enumeration of biblatex relevant issues prompts anyone to think of further issues that it might be worth going back to Chicago and APA on, to see what the status quo is, then that'd be of value.

For the moment, with respect to these issues, I don't make claims about which style choices we ought prefer generally, or by default. Nor do I mention, beyond that, specific biblatex consequences, either to the core or a standard style like authoryear.

However, if you (@plk) are agreeable, that's what I intend to do next: with the above issues in mind do some more testing and see what pops out.

## Biblatex.pdf

• Date fields. (p. 15)

hold a date specification in yyyy-mm-dd format or a date range
in yyyy-mm-dd/yyyy-mm-dd format. See Sec 2.3.8 for details. A typical example is the date field.

... to something like ...

hold a date specification in yyyy-mm-ddThh:nn[+|-][hh[:nn]|Z] format or a date range
in yyyy-mm-ddThh:nn[+|-][hh[:nn]|Z]/yyyy-mm-ddThh:nn[+|-][hh[:nn]|Z] format; and other formats permitted by EDTF level 1 .... See Sec 2.3.8 for details. A typical example is the date field.

• 2.3.9 Months and Journal Issues (p. 39)

Make clear that this field is deprecated (if that's true), E.g.

The date field can have a month level precision, e.g. date={2008-01}. So the month field is deprecated and provided for backward compatibility. A month from the date field will override the month from the month field. ...

## Bugs

• date and month: False WARN Message when date is a year only.

Given ...

  @article{kennett_2008_true,
author = {Kennett, Jeanette},
date = {2008},
month={2},
...


... a bib file compile produces ...

WARN - Overwriting field 'month' with month value from field 'date' for entry 'kennett_2008_true'

... expect: no such warning in this case. For there is no month value from the field 'date'.

When date={2008-01}, the warning occurs as expected.

## Design: Origdate in standard authoryear style

• Indulge me pointing to a difficulty in not having a origdate in the standard authoryear style, when also using an origdate supporting style (like Chicago): it prevents my bib files from being portable.

When I use biblatex-chicago I'll have an entry like

  @book{plato_2004_republic,
author = {{Plato}},
date = {2004-09-15},
origdate = {-0379~},
title = {Republic},
...


... for an output like (In the following examples bold added, italics original)....

Plato. (ca. 0380 BCE) 2004. Republic. 3rd edition. Translated by C. D. C. Reeve. Indianapolis: Hackett Publishing Company, Inc. isbn: 0-87220-737-4.

When I use biblatex (with style=authoryear), I'll need to change all of my entries to something like ...

  @book{plato_2004_republic,
author = {{Plato}},
date = {-0379~},
title = {Republic},
...
}


.. for an output like ...

Plato (ca. 0380 BCE). Republic. Trans. by C. D. C. Reeve. 3rd edition. Indianapolis: Hackett Publishing Company, Inc. 392 pp. isbn: 0-87220-737-4. Modern date published=2004-09-15

This prevents maintaining my entries in Reference Management Software. I'll have to manually maintain one .bib file manually, with all the problems of data divergence that entails.

I (by which I mean to include others in similar circumstances) might want to maintain bib file portability because, for example, when one Journal insists on submissions in Chicago, and another Journal (when submitting a paper with references that contain an overlapping subset) might have a House style which closely approximates a Biblatex core style with a few tweaks: the entries in the Reference Management Software having being setup to target one style and not the other will necessarily require post-export manual editing. All that makes a life a tad more difficult as a user - when any given work might be referenced in different papers.

This may well not persuade you. I offer it in the spirit of supplying further information. Feel free to refrain from comment on this issue.

But if it ever comes to pass that you are persuaded: allow me to ease the burden and supply various ways in which origdate could be used (as a sneak preview: I think biblatex-chicago gets it right both in output format and the options available through cmsdate).

The remaining design issues are details of two of those from my prior comment headed "The style guides on dates and datetimes". They probably need to be addressed first before dealing with the others.

## Design: Date precision correspondence

To what extent might a style guide - e.g. the Chicago Manual of Style, 16th Ed. (Chicago) and the Publication Manual of the American Psychological Association, 6th Ed. (APA) - want the publication date precision in the reference or bibliography to correspond with the precision in the in-text citation?

Note the difference between date precision and date formatting:

• "2010-02" and "2011-11-06" have the same formatting (EDTF or ISO) but different precisions, month level and day level respectively.
• "25 Jan 2013" and "2014-06-13" have the same precision, day level, but different formatting, colloquial and EDTF/ISO respectively.

### Chicago

In Chicago date precision correspondence is principally an issue for the author-date-references style, for the notes-bibilography style mostly entails an in-text superscript numeral 1. So there's no citation date to correspond to the note or bibliography.

In the Chicago author-date-references style the year alone is generally taken to be relevant part of the identifying date. So only the year tends to be used in in-text citations, which correspond to the separated out year in the reference - even if more precise date information is included (e.g. a month and day).

(In all the following examples bold is added, italics is original).

Mendelsohn, Daniel. 2010. "But Enough about Me." New Yorker, January 25.

(Mendelsohn 2010, 68)

That is, Chicago sometimes specifies an in-text to reference date precision mismatch (here 2010-01-25 versus 2010).

Elsewhere in Chicago a day precision date might be included in a citation 14.206 Citing in text rather than in a bibliography:

.... that when it comes to the aging quarterback's uncertain prospects for yet another season, "there is final, and there is Favre" (New York Times, January 25, 2010).

In which case a reference entry would be something like (going off the "bibliography" example from 14.206 and rearranging it to conform with the general author-date-reference pattern).

If that was the case there'd be an in-text to reference entry date precision match (even though the reference entry has its date separated by other publication facts).

So sometimes Chicago has a in-text to reference correspondence of the date precision; at other times it doesn't.

### APA

APA, CH 7, Ex 11 Online newspaper article:

• Brody, J. E. (2007, December 11). Mental reserves keep brains agile. The New York Times. Retrieved from http://www.nytimes.com

I can't find a corresponding in-text citation example for newspapers. However, APA, CH 7, Sec 6.20 "Personal Communications" has:

T. K. Lutes (personal communication, April 18, 2001)

So APA permits (I don't have evidence to say it requires) a day precision date both in the reference and in-text citation. That's a precision match, even though the format is mismatched.

For a reference entry APA, unlike Chicago, doesn't separate date parts with other publication facts. That makes the APA simpler.

### Biblatex recommendations

In the biblatex standard style authoryear I recommend we enable the user to make the following choices, given something like ...

@article{mendelsohn_2010_enough,
author = {Mendelsohn, Daniel},
date = {2010-01-25},
title = {But {{Enough About Me}}},
urldate = {2016-08-03},
journaltitle = {The New Yorker},
}


(In the following example bold added, italics original).

• Reference entry date precision: reflects input. In-text citation date precision: reflects input. Therefore, date precision match. (The Default).

Mendelsohn, Daniel (2010-01-25). "But Enough About Me". In: The New Yorker.

(Mendelsohn 2010-01-25, p. 68)

• Reference entry date precision: reflects input. In-text citation date precision: year only (overrides input). Therefore, date precision (potentially) mismatches. (The current situation?)

Mendelsohn, Daniel (2010-01-25). "But Enough About Me". In: The New Yorker.

(Mendelsohn 2010, p. 68)

• Reference entry date precision: year only (overrides input). In-text citation date precision: year only (overrides input). Therefore, date precision matches.

Mendelsohn, Daniel (2010). "But Enough About Me". In: The New Yorker.

(Mendelsohn 2010, p. 68)

• Reference entry date precision: year only (overrides input). In-text citation date precision: year only (overrides input). Include the finer precision date after the titles (as in Chicago), but (unlike Chicago) include the year (in effect repeating the year)

Mendelsohn, Daniel (2010). "But Enough About Me". In: The New Yorker. 2010-01-25.

(Mendelsohn 2010, p. 68)

We include the year in the reference entry when repeating the date in full, otherwise month-day dates become ambiguous for some date formats. For example in something resembling the way Chicago does it ...

Mendelsohn, Daniel (2010). "But Enough About Me". In: The New Yorker. January 25. [Don't do this]

... it is clear which elements are date elements given the colloquial "January 25". But, by contrast, if we changed alldates=ymd, we could get something like ...

Mendelsohn, Daniel (2010). "But Enough About Me". In: The New Yorker. 01-25. [Don't do this]

... which makes it look like the "01-25" refers to a journal volume-issue number. However, including the full year removes that ambiguity ...

Mendelsohn, Daniel (2010). "But Enough About Me". In: The New Yorker. 2010-01-25.

... in other words the Chicago convention of separating out the month-date (or finer) precision publication date after the publication titles, without repeating the year, is not very transferrable to an international context (where we might use an ISO/EDTF date format).

To achieve the above combination of formats [excepting those marked "Don't do this"] I recommend ...

• In the core (at least in so far as it effects the biblatex standard authoryear style):

• Ensure that, by default, date output options for date,labeldate, <datetype>date, alldates effect date precision for the in-text citations in addition to the bibliographic/reference entry.
• Add an in-text citation date output option datecite, that overrides options set by date. That is, so in-text citation date precisions can be controllably different from bibliographic/reference entry date precision.
• With respect to authoryear style:

• Add a (core) option repeatdate=always,iffirstdateinputmistached,never.

To illustrate the use of iffirstdateinputmistached ...

E.g. Given the above biblatex entry (where date=2010-01-25), date=ymd, repeatdate=iffirstdateinputmistached ...

Mendelsohn, Daniel (2010-01-25). "But Enough About Me". In: The New Yorker.

... that is, the first output date precision matches the input date precision, therefore don't repeat the date after the titles.

\usepackage[UKenglish]{babel}, date=long, repeatdate=iffirstdateinputmistached ...

Mendelsohn, Daniel (25th January 2010). "But Enough About Me". In: The New Yorker.

... that is, as before, the first output date precision matches the input date precision, therefore don't repeat the date after the titles. That the output format doesn't match the input format is irrelevant.

date=year, repeatdate=iffirstdateinputmistached ...

Mendelsohn, Daniel (2010). "But Enough About Me". In: The New Yorker. 2010-01-25.

... That is, the first output date precision (a year) doesn't match the input date precision (down to a day), therefore the date is repeated in full (according to input precision).

## Design: If dates have corresponding precision, should the formatting correspond?

Although I can't find anything explicit, the APA seems to encourage a possible scheme like ...

APA, CH 7, Ex 11 Online newspaper article:

• Brody, J. E. (2007, December 11). Mental reserves keep brains agile. The New York Times. Retrieved from http://www.nytimes.com

An APA in-text citation example I derive:

Lorem (Brody, The New York Times, December 11, 2007)

... that is, where the date precision corresponds but the date formatting is inconsistent.

One could choose to insist upon formatting consistency by changing the in-text citation spec to result in something like:

Lorem (Brody, The New York Times, 2007, December 11)

Generally I don't see any good reason for any style to have inconsistent output formats between the in-text citation and bibliographic entry.

In biblatex, presumably, if the "date precision correspondence" issues above are sorted out then date formatting correspondence will generally apply, without having to do extra work. At least in the standard biblatex styles like authoryear.

### plk commented Aug 4, 2016

 Quick question - the overwriting month bug - have you tried the latest biber? I think that this is solved already?

 Indeed, I was a bit out of date. I Downloaded latest biber.exe (64 bit 2016-08-03) and biblatex-3.5.tds.tar (2016-07-28). However, the bug is unchanged ... date = {2008}, month={2},  WARN - Overwriting field 'month' with month value from field 'date' for entry 'kennett_2008_true'. In any future posts I'll make mention of the datetime (version) stamps I'm using. But feel free to prompt me again to download the latest, if there is any doubt.

### plk commented Aug 5, 2016

 Fixed now in latest biber development version.

### JohnLukeBentley commented Aug 6, 2016

 Do you mean the month bug is fixed, but the date precision issues are outstanding?

### plk commented Aug 6, 2016

 Just the month bug. I haven't look at the rest yet - my impression is that these are not really core but rather style issues.

 Thanks. I'll wait for you, at your leisure, to have a look at the rest. They are directly style issues. But style issues that might have implications for: the included styles (chiefly authoryear); add-styles (like your APA style); and, indeed and therefore, might have implications for the core. Edit: Deleted "those".

### JohnLukeBentley commented Aug 14, 2016

 In biblatex.pdf there seems to be the suggestion that polyglossia and babel are equally supported: It is highly advisable to always specify american, british, australian, etc. rather than english when loading the babel/polyglossia packages to avoid any possible confusion. (p 117. "User Guide, Language notes, American") However, I can't get polyglossia to work, on an initial test. In my 96-dates.tex something like ... \usepackage[british]{babel}  ... works well to effect a localised date format. e.g. 11th July 100–13th Mar. 44 BCE. However, using ....  % \usepackage[british]{babel} \usepackage{polyglossia} \setdefaultlanguage[variant=british]{english}  ... doesn't work. I get July 11, 100–Mar. 13, 44 which appears to be the format of the default language (american). Is this a bug, a misunderstanding on my part (which is entirely likely), or a representation of incomplete support for polyglossia? I'm using the Xetex engine (which polyglossia seems built to support specifically, over babel).

### plk commented Aug 14, 2016

 Did you look at the language and especially the autolang package options? They control this.

 Thanks. I hadn't (and I should have). However, in 96-dates.tex with ... \usepackage{polyglossia} \setdefaultlanguage[variant=british]{english} \usepackage[style=authoryear,% alldates=long,% sorting=none,% language=auto,% autolang=langname,% dateera=secular, backend=biber]{biblatex}  ... I get \currentlang returning english (expect british or english-british) and July 11, 100 BCE–Mar. 13, 44 BCE (the american format, when I expect the british format). I get that same unexpected result using either xetex or luatex engines. If I change the \setdefaultlanguage command to ... \setdefaultlanguage{french}  ... I get \currentlang returning french (as expected) and 11 juil. 100 AEC–13 mar. 44 AEC (as expected). With ... \usepackage[british]{babel} % All polyglossia commands commented out. ... language=auto,% autolang=langname,%  ... I get \currentlang returning british (as expected) and 11th July 100 BCE–13th Mar. 44 BCE (the british format, as expected). So, under my configurations, babel and polyglossia are honoured when using \setdefaultlanguage{*mainlanguage*} . But polyglossia is not honoured when using \setdefaultlanguage[variant=*somevariant*]{english}. For all tests I'm not setting per-entry options. That is, I'm not adding to the 96-dates.tex entries any langid nor langidopts field. As always I'm loath to post here if this just ends up being a user support session. But I post on the basis there's a risk the discussion throws up a biblatex bug. Edit: "is" to "are".

### plk commented Aug 14, 2016

 You might post to TSE first to check - I think there are some issues with Polyglossia still - there has been a release pending for some time to fix some of these issues I think.

### JohnLukeBentley commented Aug 14, 2016

 Ok, thanks. That you, as biblatex developer, think it is likely (or plausibly) a problem at the Polyglossia end, will help when I post to TSE.

### JohnLukeBentley commented Aug 15, 2016

 For the record, that TSE post has progressed into: Github > Polyglossia > Exposing Polyglossia language variants to other packages like Biblatex. #154. Edit: corrected link.

### moewew commented Aug 19, 2016

 \xpg@loaded and \xpg@vloaded seem OK. The problem, however, is that even in \blx@mkautolangpoly language settings are loaded with \bbl@main@language, and that variable does not seem to hold the language variant with polyglossia. Ideal would be a backwards-babel macro that holds the language (+variant) in babel-speak and a macro that holds the polyglossia` language and variant.

 I'm going to close this particular ticket as it's getting a bit long and attracting side-discussions. I'd like to finalise the functionality for the dates for biblatex 3.5.

closed this Aug 20, 2016
mentioned this issue Aug 20, 2016

### JohnLukeBentley commented Aug 20, 2016

 @plk You previously mentioned you were going to have a look my recommendations at my post beginning Biblatex.pdf ... Date fields. (p. 15) ... hold a date specification ... (and perhaps in the light of the immediately prior post). They are significant issues.

### plk commented Aug 20, 2016

 I have corrected the docs. Month isn't deprecated.

mentioned this issue Aug 20, 2016

### JohnLukeBentley commented Aug 20, 2016

 Thanks for the doc correction (I haven't yet reviewed it). It was two whole posts, not just the section under "Biblatex.pdf", that I was trying to reference. But given the unwieldiness of this thread in virtue of it's length you could be entirely forgiven for losing the reference. That is, I agree this thread should be closed and I trust you'll find the new "Dates and Datetimes. #461" easier to tackle.

mentioned this issue Sep 17, 2016
mentioned this issue Nov 27, 2016
Labels
Projects
None yet

Successfully merging a pull request may close this issue.

None yet
6 participants