Sort non-numeric dates last
I've been trying to figure this out for hours, and I'm lost.
See also this discussion and my (rather long) post just now:
https://forums.zotero.org/discussion/882/other-options-for-date-in-press-etc/p3
When I write "forthcoming" (etc.) in the date field, the result is as desired, except for sorting. In the bibliography, it seems that it will default to "0000" for sorting purposes, so that "Smith forthcoming" is always placed before "Smith 1999" and "Smith 2018".
I've tried a number of ways to work around this in the CSL style:
--Checking if the date is numeric (it's not, and there's no other way to test)
--Prefixing it with text (or similar) so that sort should treat it as alphabetic rather than date. Zotero seems to just ignore this and insist on pretending it's still the original date only for sorting purposes, not matter how many macro layers it is embedded in.
--There seems to be no way to check what the value is, or what type of value it is, within CSL.
The answer seems to be that Zotero's programming makes a bad assumption: there's no advantage that I can think of to considering it "0000" instead of "9999", and clearly an advantage in sorting these items last. But getting an update through Zotero might take a long time, and I'm not sure what will happen to dates with coming updates anyway (see linked discussion above).
So is there anything at all that can be done within CSL?
Sorting non-numeric dates last (ascending) is obviously the correct thing to do.
I realize there are other ways I could attempt to deal with "forthcoming" etc. (see my linked comment above for why I don't want to do that), but in short this is the most straightforward way, and would be ideal if it just sorted correctly.
In the big picture, this isn't a huge problem, but it's frustrating because it's logically so simple and easy to fix, but Zotero actually seems to block access to this in the way that it forces a numeric interpretation of dates for sort.
--
P.S.: there actually is an argument to treat "n.d." as 0000, e.g., first. If a manuscript is old enough to have an unknown date, it's probably older than other dated items. That's quite different from a "forthcoming" paper. And if "n.d." is simply when there is no date added, that seems easy to accommodate. But if these must be treated the same way, then I think it's much less wrong to put "n.d." at the end (like "forthcoming") than to put "forthcoming" at the beginning.
See also this discussion and my (rather long) post just now:
https://forums.zotero.org/discussion/882/other-options-for-date-in-press-etc/p3
When I write "forthcoming" (etc.) in the date field, the result is as desired, except for sorting. In the bibliography, it seems that it will default to "0000" for sorting purposes, so that "Smith forthcoming" is always placed before "Smith 1999" and "Smith 2018".
I've tried a number of ways to work around this in the CSL style:
--Checking if the date is numeric (it's not, and there's no other way to test)
--Prefixing it with text (or similar) so that sort should treat it as alphabetic rather than date. Zotero seems to just ignore this and insist on pretending it's still the original date only for sorting purposes, not matter how many macro layers it is embedded in.
--There seems to be no way to check what the value is, or what type of value it is, within CSL.
The answer seems to be that Zotero's programming makes a bad assumption: there's no advantage that I can think of to considering it "0000" instead of "9999", and clearly an advantage in sorting these items last. But getting an update through Zotero might take a long time, and I'm not sure what will happen to dates with coming updates anyway (see linked discussion above).
So is there anything at all that can be done within CSL?
Sorting non-numeric dates last (ascending) is obviously the correct thing to do.
I realize there are other ways I could attempt to deal with "forthcoming" etc. (see my linked comment above for why I don't want to do that), but in short this is the most straightforward way, and would be ideal if it just sorted correctly.
In the big picture, this isn't a huge problem, but it's frustrating because it's logically so simple and easy to fix, but Zotero actually seems to block access to this in the way that it forces a numeric interpretation of dates for sort.
--
P.S.: there actually is an argument to treat "n.d." as 0000, e.g., first. If a manuscript is old enough to have an unknown date, it's probably older than other dated items. That's quite different from a "forthcoming" paper. And if "n.d." is simply when there is no date added, that seems easy to accommodate. But if these must be treated the same way, then I think it's much less wrong to put "n.d." at the end (like "forthcoming") than to put "forthcoming" at the beginning.
Can this be considered a bug then? What possible reason is there for "forthcoming" (etc.) to be sorted first?
I understand there is a real issue there, but that's the question of how to properly address forthcoming et al. Reversing sort order in a non-standard way because of how you want to see it implemented puts the cart before the horse.
So by your definition, it would be a bug. And by mine too.
(Note: I don't think this is a sorting issue, but a bug with how the dates are encoded in Zotero as "0000" if words are inserted. It's correctly sorting "0000" first, but incorrectly forcing "forthcoming" as "0000" for sorting purposes.)
I consider these relevantly different questions, but blurring together because of Zotero's limited date-handling. Essentially they're all the same question because the answer is "no" :)
Hm. You're not wrong.
But given that Zotero isn't perfect (no software is) I'd rather see flexibility left open. It's not standard use, so I'd assume 'use at my own risk', but if it's easy (e.g., sorting after, not before), that would be nice, versus 'punishing' my 'illegal' usage because the software doesn't have a legitimate solution. Note that any other approach here is also a hack of some sort, like using the extra field. For a lot of this, I feel like perfection is getting in the way of workable. It's interesting looking back on threads ~10 years old and seeing problems that haven't been solved and could have been solved in easy ways, but instead we're waiting on the perfect solutions.
There's also no punishing going on, i.e. Zotero isn't doing anything on purpose. It just doesn't have code in place to gracefully handle dates it can't parse, so you're seeing some default fallback.
Is it really reasonable to wait 10 years for something that should be basic functionality, when it could be implemented easily, in a decent but not ideal way?
In principle, I agree with you, but there's a tradeoff with current usability.
The help I've gotten on the forum has been great though.
I don't understand precisely what that difference would be, and since I can't see where the date is being treated in these different ways (displayed as literal text, but sorted as "0000") I'm not sure where that difference originates anyway.
Thank you for trying to narrow it down!
Note: this discussion got split across multiple threads (my fault), and there's some more info here: https://forums.zotero.org/discussion/22616/capitalization-differences-for-non-year-dates
Why do you think this is in citeproc-js? (I'm learning on the fly here, and probably missing something.)
I wonder how hard it would be to change/fix this in citeproc-js. I don't think anyone would mind if literal dates were sorted as text, after the numbers.
I don't see that file anywhere. Is that something I can change myself, or would it need to be part of a revision to the software itself?
Thank you for walking me through everything!
See: https://en.m.wikipedia.org/wiki/CiteProc
https://forums.zotero.org/discussion/comment/314188#Comment_314188
The relevant summary that I hope alerts the developers to inconsistencies is as follows: