Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Circa dates, circa date ranges, and question marked dates. Plus Eras. #427
I request support for:
It would be desirable for these kinds of values to be permissible in all date fields. I use
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:
... because it sheds some light on these issues. I could have chosen another style guide.)
Feature requests for Biblatex
Bilatex already handles:
Biblatex also provides for date ranges.
So I request the additional functionality for:
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
referenced this issue
May 22, 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.
The new date specifications are great, but I am deeply worried about one aspect:
While it’s clear that
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.
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.
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
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
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
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)
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
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
... which produces something like "878BCE" and change it to ..
... 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 ...
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
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!
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
@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.
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
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):
Spaces are optional.
So at the moment an input date is required to be formatted as either:
... or ...
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".
So the basic form, if a sign [±] is used, is:
But for positive dates and zero, ISO8601:2004 also allows for omitting the sign:
So the following is permissible:
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:
EDTF does not allow for "+YYYY".
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
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.
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.
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 ...
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:
Note that under my way of slicing and dicing it, the EDTF approximate suffix (
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
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
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)
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
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").
My motivations in suggesting this input format were twofold:
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
However, dates less than zero are unwieldy even when you are familiar with the standard. What does
It is right that ISO8601/EDTF express years less than zero as negatives like
So supporting both the strict ISO8601/EDTF (
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 ...
... 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 ...
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
Recommendation: Add "show era name less than X" functionality through an option. Either by:
Summary of Recommendations
Allow "+" sign?
How many digits for years?
Allow space between date and time?
Which strict format?
(But, again borrowing, rather than conforming to, EDTF is fine. It was a good idea to add support for
Should there be a colloquial input format?
How about a biber/biblatex option for outputing the era names below X?
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.
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:
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:
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.
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
I'm not sure which of the webpage metadate fields it comes from but it could be coming from a field like ...
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:
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
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.
Well, the Chicago Manual of Style, 16e, 14.246 “Citations of blog entries”, does list one example:
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.
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
The negative dates are printed in the bibliography but are ignored in the in-text citations.
The style can format negative dates however it wants but the default styles will use the
Allowing for the output of negative years as negative years,
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
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
Errors when using APA style.
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.
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.)
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
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.
Design: Origdate in standard authoryear style
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:
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).
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:
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, CH 7, Ex 11 Online newspaper article:
I can't find a corresponding in-text citation example for newspapers. However, APA, CH 7, Sec 6.20 "Personal Communications" has:
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.
In the biblatex standard style
(In the following example bold added, italics original).
To achieve the above combination of formats [excepting those marked "Don't do this"] I recommend ...
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:
An APA in-text citation example I derive:
... 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:
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
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 ...
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.
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
Edit: Deleted "those".
In biblatex.pdf there seems to be the suggestion that
However, I can't get
... works well to effect a localised date format. e.g.
However, using ....
... doesn't work. I get
Is this a bug, a misunderstanding on my part (which is entirely likely), or a representation of incomplete support for
I'm using the Xetex engine (which
Thanks. I hadn't (and I should have).
So, under my configurations,
For all tests I'm not setting per-entry options. That is, I'm not adding to the
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".
For the record, that TSE post has progressed into: Github > Polyglossia > Exposing Polyglossia language variants to other packages like Biblatex. #154. Edit: corrected link.
The problem, however, is that even in
@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.
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.