"No date" converted to 0000-00-00


Some items in our Zotero database have no dates, and we need to make that explicit in our citations. Therefore, we enter "n.d." (for "no date") in the date field of those items. The date correctly shows up as "n.d." in Zotero for Firefox, but in the web interface it incorrectly shows as "0000-00-00 n.d.". Also, when the items are retrieved through the Zotero API, the value also is "0000-00-00 n.d." instead of just "n.d.". Our CSL processor then puts "0000-00-00 n.d." instead of "n.d." in citations because it expects the date values to correspond to our raw input.

This looks like a bug. Is there a way to prevent date values from being converted from "n.d." to "0000-00-00 n.d."?

  • this isn't really a bug, it's more a non-existent feature, i.e. Zotero doesn't handle non-standard date input. It parses it differently online and in the client.
    For "no date," though, the answer is quite simple: simply leave the date field empty and let the CSL style insert the "n.d."
  • Thanks for the quick response. We prefer not to leave the date field empty, because filling it with "no date" does not convey the same meaning as an empty field. The former case means the document has no date, and the latter means we don't have the information on whether the document has a date or not.

    I could not find information on the expected input format for date fields in Zotero. The field seems very permissive, leading us to believe anything was allowed. If a standard date is expected, then I guess we'll be on our own and have to find a way to handle this special case (perhaps alter the data after retrieval from the API).

  • well, the field is quite flexible wrt actual dates, but it doesn't handle anything that isn't a date.
  • That makes sense. Thanks for the help!
  • (in case it comes up, it also currently doesn't handle date ranges, which is quite unfortunate. You can always put them in and they'll sync, but I can't predict what the API will do and in local citations they'll just be reduced to the first year)
  • This is actually a bug in the API. It should come through as "n.d." (and with no value for meta.parsedDate). We'll fix that. Thanks for reporting.
  • Should be fixed now.
  • That was fast!
    Just tested the API, problem is fixed indeed. Thanks!
Sign In or Register to comment.