the n.d. currently isn't actually a Zotero feature but a style feature.
I agree with Frank that it might be a good idea to go to a standard formatting, but for the time being this should be easy enough to change in whatever style you're using. Which is it?

Another question: which item type are you using for this category of material?

Okay, we'll try some rough surgery first.

Go here: http://gist.github.com/411693

then download the style, using the "Raw" link on the top right.
Install by dragging the downloaded file into an open Firefox Window.

This will eliminate the "n.d." behavior completely. If you need it for other entries, let us know and we'll work out a more targeted approach.

Please report back.

Thank you very much for the modified style! I tested it this morning and it works wonderfully.

Chris, you bring up a topic similar to one that I dealt with. There are situations in which the date -- even sometimes the year -- are not directly stated, but need to be inferred from the document content. This even occasionally occurs in published books. The brackets are the typical way to specify inferred information. ZOTERO performs well in determining "Y" and "Y M D" from dates entered, but brackets entered in the date field are not displayed when the citation is formatted through the style. I get around that by entering carrots "^" in the date field as a reminder and modifying the citation in the "Add/Edit Citation Window" editor. It would be helpful to have the ability to tell ZOTERO that date needs to be "freeform" in which no implied date format is used, and the data in the date field is presented in the citation exactly as it is entered in the date field.

also, note that support for a set of date-types is planned and/or forthcoming - so no need to keep pressing this - search the forum for original date of publication to get a sense of where development stands with respect to that particular demand.

I was wondering if the issue of adding In press instead of a date has been addressed.

I need it to follow the instructinos for Limnology and Oceanography http://www.aslo.org/lo/instructions/authors.html#References

From searching I can't find any mention in the documentation or fora other than this.

The best work around I can think of is to add the suffix to the in text reference and alter the citation in the Edit Bibliography dialogue. This works for me at the moment.

An update or better suggestions would be great.

Thanks as ever.

Thanks for the update adamsmith...

The temporary solution I am using, in case it is of help to others, is writing in the date field the text string I want to appear in the citations in my document. So under date I write "in press" or "submitted" or "to appear" depending on the needs of the current project. Given that its such a small % of citations (and mostly only my own work I'd cite this way), this seems doable for my needs.

In the past this didn't work, but with the update word add on I installed today, it is working fine. I haven't tried it yet in Lyx or Latex....

No further movement as of yet. It's just a matter of passing through a value for the "status" variable to the processor, as far as I know (easy as far as the processor is concerned, but non-trivial at the Zotero end since adding the variable will affect sync).

The new variable may find its way into the next major Zotero release (not 3.0.x, but 3.5).

push push.

No news as of yet, I guess?
When is 3.5 supposed to be released?

Gratefully yours,

The second reply to this thread seemed to have a sufficiently good solution to this issue. But I still can't see any "status" field and "pubstate" is still unused for biblatex output.

Hello all,

I'm just curious whether there has been any further development on this issue. Is there now any sort of "in press" option?

Thanks a lot.

OK, thanks for the update and other options.

I'm not sure if this is still the right place to give feedback on this (there's also: https://github.com/zotero/zotero/issues/637).

If I'm in the right place, here are some thoughts:

1. I strongly disagree with restricting the possible input of the date field, especially if it would only address the most common types (some above are even suggesting merging "forthcoming" and "in press").

The practice of using a wide variety of forthcoming types is widespread, and importantly varies by field. While you might argue that isn't the best practice, Zotero shouldn't explicitly restrict it. Individual styles can of course restrict that, but Zotero shouldn't unilaterally tell me that I have to write "forthcoming" instead of "in press" or that I can't write "in preparation", etc.

Just as one example, the most variation seems to occur when authors are citing themselves, and this is a common situation where "in preparation" comes up. I'm writing from the perspective of Linguistics, which of course has its own traditions that differ from other fields, but one important perspective there is that forthcoming citations serve a different purpose from published works: they often provide data sources (a description of a language that is in progress, for example) or just additional information about arguments, rather than any sort of scientific consensus.

So being able to cite even vaguely planned future works can be useful, and being able to specify the status seems useful. (Again, there are arguments against doing that, and some styles might not allow it.)

I can't imagine a restricted input system that would cover everyone's needs, and I just don't think that's necessary. If the field parses as a typical, numerical date, then parse it as such. If not, treat it literally, and display it that way. This will also allow other less common date systems (I see discussion elsewhere about Taiwanese dates, for example.)

2. For many author-date formats, it is standard practice to use the 'status' in place of the date. For all intents and purposes, it IS the date. "Forthcoming" should not be moved to a separate "status" field, despite how popular that is in the comments above.

This is a completely separate issue from "ahead of print" publications. For that, adding a separate "status" field would be fine, although I don't see why that can't be handled with the "volume" field (or "pages", etc.). It would be a mistake to merge "forthcoming" and "ahead of print". They mean completely different things, even though both are broadly related to future dates.

3. As others have said, treating future dates as forthcoming makes no sense on a practical level. There's the fundamental issue with the same year as publication, but there's also a problem with not allowing known future dates to be cited (rare, but it happens). Again, Zotero should not be restricting what users can do, even if it isn't necessarily best practice.

4. I'm not sure how Zotero could handle style-based differences, such as Chicago vs. APA / forthcoming vs. in press. But I'd much rather see this left up to the user than restrict us in how we can use the input fields. Most users will know the standard practice in their fields and default to that, and not need to change too often. From what I can tell, text matching and replacement like "forthcoming">"in press" is not possible in current CSL styles, so that would have to be sacrified (not included) in the styles currently. But that trade-off is worth it, rather than just having, for example, one option per style. Note that it is much easier to collapse information into a single category than it is to split it, so Zotero should encourage all possible contrasts, and as applicable collapse them (or allow users to do that manually for the final draft).

---

Now, from a practical perspective:

I'm surprised that there aren't more users echoing what @Grover20 wrote above. Just typing in "forthcoming" (or whatever) to the date field has worked for me, and I didn't even realize this was a question/problem for Zotero until I started trying to customize my own style. I assumed it was obvious that "forthcoming" would go in the date field, because it IS a date (see point 1 above).

This works almost flawlessly. I'm only aware of three issues (which I why I ended up here now):

1. Complex dates are problematic. Date ranges, unknown dates, etc. But at least using the "issued:" variable in 'extra' is a reasonable workaround for now!

Actually, my first thought in response to that would be to have less parsing of dates, to simply treat that field literally. There are a few issues with that (e.g., citing a day-month-year date in the bibliography but only wanting year to appear in in-text citations), but arguably fewer than trying to overly restrict the input that can be there. But that isn't the main focus of my comment at the moment, and it seems like there are other things going on (like "original date", etc.) that are meant to address some of those concerns.

The two points that interest me the most at the moment are:

2. Capitalization, which seems easy enough to solve, as shown here:
https://forums.zotero.org/discussion/comment/313791/#Comment_313791
The only thing I wonder about there is why a date can be capitalized and if (I hope not!) Zotero will "fix" that in the future, especially with some of these (worrying!) proposals above about restricting input.

3. Sorting
This is the big one. Zotero seems to treat any non-date input as "0000" for the year. This shows up in the sorting within Zotero's UI, which is ugly, but an easy enough convention to get used to.

However, the fundamental problem is that it seems absolutely impossible to get the CSL styles to treat the date as text rather than a date for sorting in a bibliography. In other words, any "forthcoming" paper is treated as "0000", that is, the oldest paper by that author. I've tried several workarounds-- please let me know if I'm missing something-- nothing seems to work. @Grover20 also asked about this above.

The simple solution here would be for Zotero to treat non-numeric dates not as "0000" but as "9999". If anything, that's actually more logical, because it's a future date rather than arguably one that might exist for someone writing about Ancient Rome for example. What would be even better is some way in the CSL style to detect whether a date is numeric or not, but if sorting by date treated "forthcoming" as "9999" then that wouldn't be a problem.
Cross-reference to question about this specific issue: https://forums.zotero.org/discussion/73013/sort-non-numeric-dates-last

--

Alright, I've written a very long post here. But I do hope these thoughts may be helpful for someone. The solution as-is of just using literal text in the date field almost works smoothly. I'd strongly encourage using that rather than attempting to anticipate the "important" options people might want, then restricting others.

Thanks for the reply.

The problem isn't "correctness", it's that there are many standards. It's clear from the discussion here, even among those who agree that restricted input is the best approach, it is not clear which style to follow. That's not going to work out well in the long run.

You're right about my long reply, and I'm sorry about that. But I really feel this will be a mistake for Zotero, and it will be hard to undo once implemented, so I wanted to express some complex thoughts about it.