Normalization of date fields for CSL

I'm currently doing a review of this module to determine if I want to use it for my own new website (I'm about to start on my Ph.D. dissertation and am building a place to document the process!), or try to roll my own custom built solution, and so far the only hangup I have is that dates don't use proper Drupal date fields. Other than that, it's an amazing body of work. Are there still issues with dates like this? I wish we could capture the day along with the month and year for publication date, for instance, if that info is available. I haven't tested how this module interacts with Views, but I am hoping that we can setup filters to filter them by date as well wherever needed, and choose per bundle what date format we want. I remember in the past having difficulty with that in Views when dates are text fields...

Any site that uses data from D7 migrated using bibcite_migrate and the format will be either "mm/yyyy" or "mm/dd/yyyy".

The current code is:

    return [
      'date-parts' => [
        array_reverse(explode('/', $value)),
      ],
      'literal' => $value,
    ];

I think it'd be worth building some settings to control this, because it's all really vague.

A simple patch that changes the logic to work with dates in the format "mm/dd/yyyy" for compatibility with migrated data.

This should be configurable globally to control the format.

This updates the date field description to note that the date should be in the format mm/yyyy or mm/dd/yyyy.

This should be configurable globally to control the format.

Damien, given the statement above, is there additional work needed for a full solution so that this *can* be configured in the UI, separate from the fix that assumes either mm/yyyy or mm/dd/yyyy in the patch above?

Cross-referencing 🐛 Publication Date should support more than "Year" (e.g., article in a newspaper APA format) Active , which involves changes to another field that is processed using the extractDate method described here.
In sum, there are three fields that would be affected:

    'bibcite_year',
    'bibcite_access_date',
    'bibcite_date',

is there additional work needed for a full solution so that this *can* be configured in the UI,

Thinking about this further, I conclude that this *does* need to be a configurable option in the UI, since there will be potentially existing sites who have entered date format in dd/mm/yyyy format, where this proposes to support mm/dd/yyyy, and a previous comment suggested matching the citeproc's yyyy/mm/dd format.

Therefore the remaining work, as I see it:
1. Decide on a new default for new installations of this module, or just decide to keep it supporting dd/mm/yyyy format to prevent disruption for people used to using this module currently. No change should occur to existing sites, regardless
2. Add a new UI setting for configuring whether the date format should be dd/mm/yyy, mm/dd/yyyy, or yyyy/mm/dd.
3. Add logic that will update the form fields' descriptions to match the site-configured setting in #2