Datetime. Missing frills and datetime output, authoryear style, and mergedate. Bugs. #520
Comments
JohnLukeBentley
changed the title
JohnLukeBentley
changed the title
|
Unfortunately I'm not really well-versed in the new date-time features, so I can only make tentative suggestions. If I understand things correctly, we need to replace (all?/most? occurrences of) the two simple lines by the much longer and harder to understand @plk Do you think it could be possible to conflate the monstrous 28 lines above that have to be repeated over and over again in all sorts of places into one more comfortable standard command? Earlier it was fairly neat to have only the two lines in all sorts of places, but having to have the 20-odd lines everywhere makes the code just look terribly complicated. Additionally, in all by Plus one needs to be This should address your issues (1) and (2). (3) is expected behaviour, dates for I have uploaded a amended |
|
@JohnLukeBentley Did you have time to take a look at my suggested |
|
Well there's a coincidence. Notification of your original detailed response didn't properly end up on my to do list. I happened to rediscover this thread a few days ago (I'd been away from biblatex in general). I had started testing your gist then; and have just sat down to do some more testing on it. The short of it is:
|
|
No hurries. |
|
Part way through my testing some issues arise. New test filesI'm currently using the following testing files that are a bit more "minimal" (as in "Minimal Working Example") and hopefully easier to work with ... The problemWith the following options (as well as the rest of the options as set in, in Biblatex-Tester-BasicExamples.tex) ... ... Issue (1: eras, approximates, uncertainties) is solved for all combinations of However, for To examine the problem note, firstly, the relevant output when However, when ... which is not necessarily what we'd expect: the datetime precisions are lost entirely. (The lonely "In:"s can be ignored as merely an artifact of unrealistically spartan bib data). I suppose for For further comparison, the text in
... in
When Note, however, with the following options ... ... and Our GoalSo for datetimes finer than a year it seems that what we need is ...
My analytical powers are not with me today (I'm a bit tired) so I'd be relying on you @moewew (and/or @plk) to double check that's the best way to analyse the problem and formulate "Our goal". |
|
Thanks for taking time to test the suggested code. I hope to have a closer look at this over the weekend. I also noticed that one could get undesirable output if |
|
Yeah we don't wont to break backward compatibility. I haven't thought the following through but, to avoid a major re-write, we might want to say that some combinations of options will not be supported by Feel free to pass the ball back to me after having a closer look at it but before coding, if you doesn't all fall into place for you. I probably should have written the above more clearly: to properly enumerate what we expect for various options and data. Properly describe the test cases, that is, that the code needs to target. Not that I'm better able to do this than you (it's probably quite the reverse), but as a matter of properly sharing in the duties. In any event: no hurries back at you. |
|
Note that since The problem is that even currently we are breaking backwards compatibility for dates with |
|
@plk Any comments here? It is clear that I would like to ask again about the long and complicated code that replaces Would it be possible to conflate the former into a new macro? I seems to recall you argued that this is a style-specific thing and that we don't need a macro for it. But seeing that the code needs to be replicated at several places, I really think that it would be a good idea to make it into a macro. Ideally I would like it to come from |
|
Well, I can't remember exactly but if you want to try branching and change it, I can run the test suite for the dates as that does test most of the date formats. |
|
@plk I have #593 to fix the easy parts. As you can see the number of lines explode and we have a lot of redundancy. I'm quite unhappy about the fact that we had to copy the lines from The other things are much more complicate as has emerged here and requires thinking about expected output, as well as how to achieve it. |
Fix the easy bits of mergedate (see #520)
|
@plk I had another look at the more complicated bits of For If For Have a look at moewew@aa2e0a5 for a first attempt. |
|
@JohnLukeBentley Finally I found some time to have a look at this. We have committed a bit of code to deal with |
|
@moewew Thanks for doing that. Life has me busy at the moment. But I hope to get back to it shortly (leaving "shortly" undefined for the moment). |
|
No need to hurry. It would have been nice to have another pair of eyes checking the output before we release a new version. But things should be OK now. And if you have complaints after we release then we can look at getting it into the next release. Upon re-reading I think that what was implemented in the end is not exactly what you suggested. But it should allow one to obtain sensible output with all most combinations of options while at the same time retaining as much backwards compatibility as possible. |
|
After some testing it looks like you folk have solved the original test cases. Some mighty fine work there! However, that has enabled me to see further and to throw in another test series, for which the current code fails (at least by my lights ... you may have good reasons to not want to accomodate the new test series). I've run an initial test with: The original issues were:
That looks addressed.
I see from testing that this has been at least partially sucessfully addressed. However, it might be better, now, to understand this issue in more general terms: that for datetime precisions finer than a year the citation and bibliographic output is consistent with the spirit of the various
.
3 was not tested. As you previously mentioned the original results I received were by design (based on entry type). I've just taken your word on this without much thinking it through. I also haven't placed much attention to the nuances around the For the results that follow, numerals that correspond to the above issues are listed in brackets. Where a numeral is:
Test Series 1Using ... Varying the value for false (1,2), minimum (1,2), basic (1,2), compact (1,2), true (1,2), maximum (1,2). That is, everything passes. I know "true" is an alias for "compact": I test it anyway. Test Series 2Varying the value for false (1,2), minimum (1,2), basic (1,2), compact (1,2), true (1,2), maximum (1,2) That is, everything passes. Intermediate conclusionIn short, for the original test cases: the absent approximate, uncertain, eras issue (1); and the issue of the proper handling of precisions finer than a year (2): that looks all fixed. HighlightsConventionalI'd like to highlight some significant combinations of values and demonstrate how well the current mergedate coding works for precisions finer than a year (for the origingal test cases). That combination probably expresses a conventional citation/bibliography format. That yields something sensible: All that supports a beautiful conventional format. Time details can be readily found a the end of each bibilographic entry. Day level precisionIf you wanted to have a quirky day level precision in the citation and bibliography (something I've been pushing for) you could use: ... yielding ... Of particular note are the "Times" entries. Under this scheme detailed information about times is available by exact matching the citation with the bibliographic entry, then scanning to the end of the line. In effect that works like the conventional year matching scheme: but this time we match on a day (if avialable). All that works well. New case fails: Time level precision (Error)If you wanted to have a quirky time level precision in the citation and bibliography (something I've also been pushing for) you could use the following (changing Test Series 3Varying the value for false (1,2), minimum (1,2:fail), basic (1,2:fail), compact (1,2), true (1,2), maximum (1,2). That is, For example, for
But for
... the same output as for
I think that would conform to the spirit of 50-style-authoryear-biber.pdf (which still speaks in the old terms, which assumes year precision) ....
...
I note elsewhere @moewew you've mentioned that there are new draft's of ISO 8601 which deprecate, by incorporating, EDTF. I've yet to catch up on that issue but at a first glance it doesn't directly affect us on the mergedate issue (from memory @plk identified the main issue as the character for dates that were uncertain and approximate). |
|
Thank you for taking time to look into this again. I think it is safe to say that the whole To make things work with all settings we would need something far more intricate. I might be barking up the wrong tree, but at the moment I think a new system would 'simply' need to be able to assess if |
Thanks. I missed that. But I see now. With ... ... I get ... .... the "Baker, Anne" bibliographic entry does not merge when we would expect it to (under the former scheme).
I suppose, then, the options would be to:
For for time level precision the following, or something like it, could be given. For ... ... the result ... So the current state of play essentially gives me what I was after: to be able to present to the reader, as an author of an essay, precisions finer than a year in a variety of ways that are not confusing (e.g. imaging I, or others, would be writing an essay about a twitter storm that happened over a 24 hours period where times might be informative). The remainder seem to merely involve niceties around aesthetic choices in the bibliography. In short, I'm persuaded not altering the code, in terms of |
|
I'm a bit torn at the moment. On the one hand I'd love to make
|
Detect if \printlabeldateextra and \printdate have the same level of precision. Previously the detection was hard-coded assuming year-only precision for labeldate and full precision for date.
|
OK. I had a look at this in moewew@5c08d06. @JohnLukeBentley If you want to test this, simply put https://github.com/moewew/biblatex/blob/5c08d06e3fb29113c07d83a79d87646623d47094/tex/latex/biblatex/bbx/authoryear.bbx (this exact version) in your test folder. @plk My reservations against this still stand. Let me know if you think this is worth it. If we decide to merge this, we need to think about the command names first. Maybe some of them should be private, or they should be moved to |
|
I think that making the commands public is a good idea - you can't have too many tests available and I also think that long descriptive names are fine as it makes future extensions easier. I do understand the reservations but I think that with these changes, it's a good situation and we can revisit more fundamental changes when the new ISO8601 is ratified. Will you merge in the changes and document the commands? |
|
OK. I made the commands public. (Hopefully correctly.) Will submit a pull request. |
Improve mergedate minimum and basic (#520)
|
I'd like to close this ticket since the discussion has become quite long now. We probably need to open a new issue about the EDTF/ISO transition. Discussion here should be limited to the mergedate issue (which are hopefully solved now). |
|
@moewew Just to let you know I'm working on this a little bit each day, using your authoryear.bbx. It looks like you have solved the last handful of cases. However, I'm having to wrestle with my own confusions before giving detailed feedback. I also have my eye on #540. In short, thanks for your recent efforts on this ... I'm still on it. |
|
If you want to test now, just get the newest development versions of #540 will probably not be solved, but at the moment that it not high up my priority list, seeing that we will have to overhaul the whole EDTF/ISO thing with the advent of the new ISO anyway. |
|
@moewew thanks for that coding! And with thanks: I'm on a fresh download of the biblatex and biber dev versions from sourceforge. ISO
@plk's suggestion, if I recall it correctly, that we stick to EDTF until ISO progresses to some firmer milestone seems right. If that is right, then is there anything for us to discuss until that milestone is reached? I mean do you have in mind a discussion around the ISO draft from a biblatex point of view to come to a collective conclusion about what ISO should look like, in order to then lobby in the ISO forum? Merging datesYou sound a bit equivocal about whether you want to close this thread. If you'd like me to close this thread and start a new one dedicated to the mergedate issue: I'd be happy to do that if that helps keep things uncluttered. For the moment I'll take your last prompt and continue the mergedate discussion here. Your coding certainly solves the last set of cases I talked about. So now I have ... The results for "2" are essentially all we need to look at. Issue "2" (from the first post) is essentially the issue of the merging of dates. To illustrate why I'm not sure about some of the results, take an entry with datetime precision and config 1 ... ... with ... but with So that might make conceptual sense given what "compact" historically was intended to achieve "merges all date specifications with the date labels".
At this part of my day, when my brain gets soft, I'm not sure what to suggest. But perhaps if I pass the torch back to you, you'll be able to see matters through. But I'm might offer some more vague thoughts ...
Yes that'd be a legitimate concern. I can't help wonder if it wouldn't make it easier, both for users and coders (i.e. you), to reduce the mergedate options. E.g. To three: none (alias false), basic (alias true), maximum. But maybe @plk has a story to tell about a prior battle to get, and the importance of, the 5 values we have today. |
|
Re the ISO discussion: I just don't want to make this thread bigger than it already is by discussing EDTF/ISO issues here. I don't know if we need to talk about it at the moment, but if so, I'd rather not do it here. Thanks for testing this again. I'm for obvious reasons quite eager to close this issue, but of course only if the As far as I can see you are only unhappy/unsure about The options follow my interpretation of what I don't think we can remove some of the mergedate options, they have been with us for too long, even though I doubt they are widely used. Since some of the |
Yes, that was correct.
Thanks. That interpretation convinces me that the compact and maximum, and therefore all the combinations I've tested, are as they should be. Your explication is clear but my crude summary is: when merging occurs On the number of So at least as far as the coding goes I think this But might there be a documentation task, e.g., in updating With a proper sense of duty I should put up my hand to offer a draft ... but, given that in general the coders should write the docs, perhaps it something you might like to take on as a (low priority) task ... if you see value in it. |
|
Thanks! Just looking at 50-style-authoryear.tex/*.pdf in that commit I think your explanations are largely spot on and properly economic. You might have a repeated error, however, in two of your examples. For
... when it ought be ....
... at least if it is to conform the results I'm getting when I run with something like ... ... but perhaps you were trying to illustrate "even if it is printed in the position of the date label" (??) ... but I wouldn't be sure how to achieve this with a date that has day level precision. Perhaps another example could also be thrown in with timezone level precision "Doe, John (2016-06-06 18:20 +10:00) ...". A separate suggestion would be to explain "precision". You and I are familiar with its meaning but I suspect newcomers might be a bit thrown. So perhaps a sentence or two in the introductory paragraph. Something like ...
All this raises the prospect of providing a separate example pdf that illustrates varying datetime precisions (an example pdf that doesn't discuss |
|
Thank you for the feedback. I have fixed the obvious error you pointed to with I was not too keen to add even more examples with time zone and whatnot. If people really use these things, they should experiment with the settings anyway. I did not want to add a whole paragraph about the 'precision' issue, so I just added 'date time granularity' in brackets. Hopefully that does not make things worse. I'm not that comfortable writing these docs and I don't think they are read that often anyway. If you think a longer explanation might be helpful, feel free to submit a pull request with your suggestions. |
|
'date time granularity' in brackets works well I think. I'm happy you should reject the suggestion of further examples (for this document). And I see the error fixed in the commit. If I think that datetime precision requires further exemplification it would probably be better as its own document anyway. If I get to it I might make a case for it in a comment or pull request, as you suggest. So the current issue is closed. Thanks very much for all that! |
Some of the datetime frills (approximate, uncertain, eras) break in the authoryear style when mergedate is other than the default ("compact" or "true").
With ....
... then output is as expected (bibliographic output in document, not alphabetic, order):
With
... then output breaks:
This is broken in three ways:
The datetime frills (approximate, uncertain, eras) are absent from the first date; and
Where a bibliographic entry has a
datefield with datetime precision finer than a year the fulldate time is sometimes not printed out as a second date. Here the entry for Alberici is correctly printout out, but for SEP there is no second date supplying the season. I'd expect:Perhaps this is only an issue with seasons.
Where a bibliographic entry has a
datefield with datetime precision of a month the second date sometimes is surrounded by parentheses (as in Kennett, an article type), sometimes not (as in OED online, a book type).Request fixing this up for
mergedate=basic, if not all the other mergedate options (At the moment I'm personally only intrested inmergedate=basicandmergedate=compact).In the following test files only the entries for Aquinas and Plato are directly relevant. However I supply other entries of varying datetime precision, as a guard against regression.
Gist "Biblatex-Bug-Mergedate" (Edit 04: note to self these are locally renamed Biblatex-Tester-EdtfBasics.*):
Edit01:
labeldateusetime=falseEdit02:
@book{oed_online_2016_oed, ...entry to Biblatex-Bug-Mergedate.bib to support this.Edit03:
"Edit 04: note to self these are locally renamed Biblatex-Tester-EdtfBasics.*"
The text was updated successfully, but these errors were encountered: