Year of retrieved date gets disambiguated but shouldn't


I am using

<date variable="accessed">
<date-part name="year" form="long" suffix="-"/>
<date-part name="month" form="numeric-leading-zeros" suffix="-"/>
<date-part name="day" form="numeric-leading-zeros"/>
<date variable="accessed" form="numeric" date-parts="year-month-day"/> <!--this produces>

to call out the date of retrieved stuff in bibliography, but the year gets a suffix added for disambiguation - the same behaviour as in the in-text citation.
But at this place, I do not want the date to be disambiguated - so what can we do?

I just checked some other styles, and it is not happening there, but I didnt find out what I am doing wrong....

  • edited June 23, 2013
    We'll need to reproduce that, I think, before we can say why it's happening. Can you post both the style you're using and sample items that show the fault to ?
  • The initial question would be whether there is an "issued" date in the bibliography.

    To be sure I understand correctly, do you require that the disambiguation suffix attach to another date in the citation, or that it not be used at all for citations of a particular type (and so leaving the citations in an ambiguous state)?
  • Hi,
    many thanks for answering so quickly!
    Its about the din1505 styles, for example

    and indeed it is also showing the year in disambiguated form as it's an author-date style.
    But the problem described above does not happen in most other author-date styles. It seems I am too dumb to find out why :)
    here is a small sample dataset that show the problem as described:

    in the bibliography this looks like:
    Websiteauthor, One: Testwebsite 2 author title date. URL - abgerufen 2009-a-09-10. — Title of Site
    Websiteauthor, One: Testwebsite author title date. URL - abgerufen 2009-b-09-10. — Title of Site

  • Have you tried setting the year-suffix explicitly where it is required (both in the citation and in the bibliography)? The code would look like this:
    <text variable="year-suffix"/>
    When it is set explicitly, the processor will not try to guess where it belongs, which seems to be the cause of the problem.
  • Hi Fbennett,

    excellent, this fixed the problem! Many thanks!!

Sign In or Register to comment.