I would like to update this wish, since it seems to be a fairly easy enhancement that would make life a lot easier and the developers did not seem to take notice.
best
Michael

Also, if I only type 2008-12, zotero does not display y-m.

This is now fixed in the latest dev build. Thanks.

if I, as a non anglo enter as a date for a journal article for july 4th, 1972," 4-7-1972" zotero writes next to the field "y-m-d", which is maybe a bug

The y-m-d just indicates the values that it parses, not the order. We could adjust that, but it's working as intended.

In fact, it cannot parse correctly, because unless the number of the day is higher than 12, how should it find out which number is date and which is month?

Zotero determines ambiguous dates based on the user's Firefox locale. If you use a non-U.S. version of Firefox or change your user interface language, it will parse 4-7-1972 as July 4th.

You can also write "July 4, 1972", "Juli 4, 1972", "4 Juli 1972", etc., regardless of your locale, since it looks for the short forms of English months. If you were using, say, an Italian locale, you could also write "4 luglio 1972", since it also looks for the short forms of months in the current locale.

The reason you're having trouble now is that you're using a U.S. English build of Firefox with unmodified locale settings and are trying to enter ambiguous dates in a European format.

"Summer 2008" was only one example. There are many possible date values, including things like date ranges that wouldn't work well in a three-field system. And there's no need to make dates less readable and more tedious to enter by splitting them up. Computers are smart—they should handle this stuff. (This is why, for example, Google Calendar allows you to type "Dinner with Michael 7pm tomorrow" in a single field.)

Just typing a date in whatever format you want seems fairly intuitive to me. Problems should be pretty rare, as they'd mostly only occur if people were using a U.S. Firefox build with unmodified locale settings and manually entering an ambiguous date in a purely numerical format. If the y-m-d indicator showed the parse order, it'd be obvious if the order was something other than what was expected. There might be other ways to improve clarity as well, but switching to an awkward multi-field system doesn't seem like a very good one.

How are date ranges handled?

At the moment they're not. There's a ticket that would allow date strings that weren't parsed cleanly to be passed through as-is to the CSL engine, and I think Frank's new CSL processor will support that. I'm not sure if there's explicit date range support in the new processor—if so, Zotero would presumably need to parse it and pass the values through, which wouldn't be very difficult.

I don't know that we need to bother doing anything else with date ranges elsewhere in Zotero. There might be some things we could do regarding sorting or searching or the timeline, but those wouldn't be big priorities.

(1) that Zotero pass through the parsed date to the processor, and drop the cruft on the floor; and (2) that a date field enclosed fully in quotes be passed through as a literal, regardless of the content, with the quotes stripped.

(1) is the current behavior. As for (2), why bother with quotes? Zotero knows what it supports—and will be made to support as much as the processor supports—and can also discard obvious cruft (e.g., periods after shortened months), so why not just pass through the full string as a literal if it's not a clean parse? The field is designed to be flexible, and I'd like to avoid requiring users to manually mark up the data, since it's more work for them and more work for us everywhere we need to handle that data.

Is it possible that the fixes mentioned here could also be helpful to the issue of original dates (which can not be output in brackets or parens under the current version of zotero)? That is, once developers are tinkering with how dates are entered, perhaps both sets of issues could be resolved?

Like migugg Aug 3rd 2009 (above), I also found the "y m d" to be very confusing when it appeared next to dates I entered as "August 20, 2009" or "8-20-2009". I thought the "y m d" appearing meant it was interpreting the last "word" in the date ("2009") as the day. Searching the web, I eventually found this discussion, which cleared things up. That's much too hard. Instead of "y m d", It would be better to show the date in some unmistakable format (like "20Aug2009") or even just put some indicator of successful parsing ("OK!" or "Bad!"?). Better yet would be some help function, maybe saying the user can hover over the field to see the stored value.

I do like having a single date field - it speeds data entry. The hover-over display of the parsed date is good, too, although I did not discover that until reading this discussion.

JonEP's suggestion actually might be a reasonable workaround for the original date issue, which is quite urgent for several of us. That is, pass a string if the date cannot be fully parsed, which would give us 1983[1856] as a workaround for original dates.

Not read this discussion carefully, but will just note that from the CSL perspective, this issues has not been resolved (e.g. I'm pretty resistant to the notion of pass-through literal dates).

Could the date fields please be made to intepret "today" and/or "now", or even better, ofer a right-click option for this?

Sure - I want to use it as a quicker way to input or update the date in the "Accessed" field, for example when I manually create an item for an online resource such as a blog post, or when I download and manually attach an updated copy of someone's manuscript from their web page.

I prefer Rintze's option - seems both cleaner and more intuitive.

What is the scope of issues to be settled?

Citeproc-js currently accepts date information broken down into year, month, day, season, and a circa bit. To handle cases in which the calling application cannot provide those details, it will recognize a "literal" entry in lieu of a structured date. Passthrough is not an ideal solution to unparsed dates, but the alternatives (silently leaving the date empty, placing an error slug on the output, or passing a corrupted and possibly misleading date) are worse. Literal strings are rendered without special formatting. I don't see what else one could do with them, since nothing is known about their content.

I'll be happy to change the processor interface if it will help in some way; I put the interface description online in the hope of receiving feedback on things that should be altered. But so long as everyone is in agreement that some form of literal passthrough is to be recognized (which does seem to be necessary), a standardized interface that includes that possibility, when it is settled, could also be left for implementation in an intermediate layer, independent of the processor.

(PS: Just to amend what I wrote earlier, we do have ranged date support in citeproc-js now.)

Frank's processor supports a 'season' element, so "Summer 2000" will be fully structured (and localized).

RDF import/export isn't my department, so I can't comment on that.