Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datetime. Ranges bug. #539

Closed
JohnLukeBentley opened this issue Mar 1, 2017 · 6 comments
Closed

Datetime. Ranges bug. #539

JohnLukeBentley opened this issue Mar 1, 2017 · 6 comments
Labels

Comments

@JohnLukeBentley
Copy link

JohnLukeBentley commented Mar 1, 2017

Biblatex-Ranges-Mwe.tex:

\documentclass{article}
\usepackage{a4wide}

\usepackage{filecontents}
\begin{filecontents}{\jobname.bib}
% Canary in the coalmine  
@article{chalmers_1995_typical,
  author = {Chalmers, David J.},
  date = {1995},
  title = {Typical citation of a modern work}
}
% Unknown
@book{simpson_cool_book_0092,
  author = {Simpson, Lisa},
  title = {Cool Book 0092},
  date = {unknown/2006}
}
\end{filecontents}

\usepackage[%
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Dates and Datetimes
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % julian=true,% convert dates before gregorianstart to Julian Calendar
    % gregorianstart=1582-10-15,% Default
    alldates=ymd, % year, short, long, terse, comp, ymd, edtf. ymd = Year-Month-Day format
    labeldate=year, % year, short, long, terse, comp, ymd, edtf. ymd = Year-Month-Day format
    alldatesusetime=true, % print time components in non-compact date ranges
    labeldateusetime=false,
    alltimes=24h, % 12h, 24h, 24hcomp. 
    seconds=false, 
    timezones=true,
    datezeros=true,
    % dateera=astronomical (default), secular, christian
    %   astronomical dates, controlled by datezero
    %   secular (prints BCE/CE) controlled by dateerauto, datezeros
    %   christian prints BC/AD controlled by dateerauto, datezeros
    dateera=secular,
    dateeraauto=501, % Sets the max year ceiling for automatic printing of era
    abbreviate=true, % prints full localisation strings
    dateabbrev=false, % prints full date localisation strings
    dateuncertain=true,
    datecirca=true,
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % Style
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    style=authoryear,
    sorting=none,
    dashed=false,
    url=false,
    %refsection=section,
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % style=authoryear option
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    % mergedate=  % false, minimum, basic, compact or true (default), maximum.
    %    See \doc\latex\biblatex\examples\50-style-authoryear-biber.pdf
    mergedate=basic
]{biblatex}
\addbibresource{\jobname.bib}

\begin{document}

Canary in the coalmine: \autocite{chalmers_1995_typical}

Range Unknown: \autocite{simpson_cool_book_0092}

\printbibliography

\end{document}

Errors:

line 65: Package etoolbox Error: Toggle 'abx@bool@dateunknown' undefined. \endentry
line 67: Package etoolbox Error: Toggle 'abx@bool@dateunknown' undefined. ...Unknown: \autocite{simpson_cool_book_0092}
line 70: Package etoolbox Error: Toggle 'abx@bool@dateunknown' undefined.
: Overwriting file `./Biblatex-Ranges-Mwe.bib'.

Commenting out Range Unknown: \autocite{simpson_cool_book_0092} removes the error (the tex file compiles OK.

That's with authoryear.bbx that I last downloaded from sourceforge, not @moewew's authoryear.bbx from #520. But the file above also fails for moewew's authoryear.bbx. There's a chance I'm out of date. Can anyone reproduce the bug?

Edit: "OK0" to "OK".

@moewew
Copy link
Collaborator

moewew commented Mar 1, 2017

The exact MWE runs fine for me with biblatex 3.7/Biber 2.7 from MikTeX's repository.

@JohnLukeBentley
Copy link
Author

OK thanks. Updating removes that bug.

However, we (@plk) might want to review ranges output.

I have a new Gist: Biblatex Ranges Basic containing Biblatex-Ranges-Basic.tex and Biblatex-Tester-BasicExamples.bib. That spits out a 2 page pdf with three range sections: Unknown, Open, and Unspecified.

Note particular options that I've set as follows:

alldates=ymd, 
labeldate=ymd, 
mergedate=false

When the date(time) is a range we probably want to output it as such:

  • For in-text citations. For example for unknown/2006 I get (Simpson n.d.[a]) when perhaps we should have (Simpson unknown/2006a), or (Simpson unknown/2006) - using 'unknown' or 'open' as appropriate.

  • For references. For example for "open/2004-01-01" I get

    Simpson, Lisa (n.d.[a]). Cool Book 0097. /2004-01-01.
    

    ... when we should perhaps get ...

    Simpson, Lisa (open/2004-01-01). Cool Book 0097. open/2004-01-01.
    

    ... or, if we changed the options such that labeldate=year ...

    Simpson, Lisa (open/2004). Cool Book 0097. open/2004-01-01.
    

All this is before considering mergedate issues (mergedate=false above).

@moewew
Copy link
Collaborator

moewew commented Mar 4, 2017

Maybe you want to move this into a new issue, so we keep things clean and separated. (BTW: I find that testing becomes much easier once the .bib file is included into the .tex with filecontents. That then involves less hassle for setup.)

@JohnLukeBentley
Copy link
Author

I'd suggest it's still, arguably, a "Datetime. Ranges bug", albeit not the original alleged bug. On that basis it strikes me as cleaner to keep things in a single thread especially given the original "bug" turned out not to be.

But if, even after that suggestion, your preference remains for a separate issue, I'll be happy to create one.

The idea behind splitting the (both largish) files was that it might make it easier for you (and others in general) when concentrating on what's going on in the .tex file. I do see that it is easier to download a single file. I had a different sense on where the larger hassle would lie.

In addition at my end I have separate test files that reference the same bib file. So having separated files in a gist better enables me to match them up with my local files.

But I will keep your preference in mind for future. As a matter of course, for the smaller MWEs, I try to make it a single file (as I did in the first post).

In any event, thanks for raising those two matters. Would you rather I create a separate issue after all?

@moewew
Copy link
Collaborator

moewew commented Mar 4, 2017

Mhhh. Splitting off the 'unkown' issue will allow you to choose a more appropriate title. And it will allow people reading the issue to come to the problem directly without having to read through three posts just to find out that this has been solved and that the problem has changed. I prefer many bite-sized short issues instead of one massive one.

@JohnLukeBentley
Copy link
Author

Actually, it's an issue with all the range types: unknown, opens, and unspecifieds (although perhaps no change needs to be made for unspecifieds).

But I've create a new issue #540 "Datetime. Ranges: Unknowns, Opens, and Unspecifieds".

Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants