Views argument for the datetime module should use maths.

Thanks for the initial patch. Changing this to a feature request, as it wasn't present in Drupal 7 / Views 3. I am really surprised I have never run into this situation before, but I see how this can be useful.

I don't think we would be able to deprecate the other arguments, as I suspect that would be an upgrade and migrate path nightmare and we don't want any API changes at this point. Also, in theory, we should be able to add validators to those to range check the existing ones. Instead, I would remove the fixed date option, and just have this handle computed dates (what you called offset dates).

#2489476: [PP-1] Base fields miss out on Views data from hook_field_views_data() may (or may not) complicate this issue, or change its approach.

Computed dates in the URL also require adding a cache context (probably to make it non-cachable). Not sure how to handle that with an argument plugin.

Added a few tags. We will eventually need a Beta Eval, but not until we iron this out a bit more.

1. +++ b/core/modules/datetime/datetime.views.inc
   @@ -28,6 +28,7 @@ function datetime_field_views_data(FieldStorageConfigInterface $field_storage) {
          'day' => t('Date in the form of DD.'),
   +      'calculated' => t('Calculated Date.'),
        ];
        foreach ($arguments as $argument_type => $help_text) {
   

   Do we use the term "calculated" or "computed" more in core? I think "computed" may be more appropriate in this case.

2. +++ b/core/modules/datetime/src/Plugin/views/argument/Date.php
   @@ -7,7 +7,7 @@
    
   -use Drupal\views\Plugin\views\argument\Date as NumericDate;
   +use Drupal\views\Plugin\views\argument\Date as FormulaicDate;
    
   

   Even though this is just an alias, I think this is too disruptive. I would rename your new class "ComputedDate" to match the argument key. This makes even more sense if you just have it handle computed dates.

3. +++ b/core/modules/datetime/src/Plugin/views/argument/NumericDate.php
   @@ -0,0 +1,332 @@
   +  // Flag to allow the use of date offsets for default arguments.
   +  public $canUseOffsetDate = TRUE;
   +
   

   Bad docblock format. Does it really need to be public or should you have a getter instead? I also think the general convention in Drupal is not set the initial value here, but in the constructor.

4. +++ b/core/modules/datetime/src/Plugin/views/argument/NumericDate.php
   @@ -0,0 +1,332 @@
   +
   +  function title() {
   +    $title = parent::title();
   

   Needs docblock and access declaration. This happens several times in the patch.

5. +++ b/core/modules/datetime/src/Plugin/views/argument/NumericDate.php
   @@ -0,0 +1,332 @@
   +
   +    public function query($group_by = FALSE) {
   +    $this->ensureMyTable();
   

   Bad indent. Needs docblock.

6. +++ b/core/modules/datetime/src/Plugin/views/argument/NumericDate.php
   @@ -0,0 +1,332 @@
   +  /**
   +   * Options form subform for setting the operator.
   +   *
   +   * This may be overridden by child classes, and it must
   +   * define $form['operator'];
   +   *
   +   * @see buildOptionsForm()
   +   */
   +  protected function operatorForm(&$form, FormStateInterface $form_state) {
   +    $options = $this->operatorOptions();
   

   Needs @param in the docblock.

As for how useful, I use the YYYY and MM arguments all the time when building things like blogs, and need yearly and/or monthly archives. I've used DD once or twice.

I'm sure you can come up for a use case for using operators for computed date arguments, but in all of the cases I could think of, an exposed filter fit the bill better on sites I have done. I'm gong to let others chime in, though. I'm mostly neutral on this as is. The VDC people should see this, too.

If we do want this feature, I think adding operators to the existing arguments and adding a full date argument w/ operators may be best. Adding operators would require an upgrade path + tests, as it would be a schema change.

Allowing operators on date arguments from the URL has caching complications, and D7 and earlier made this tougher to handle in a sane manner. With exposed filters, the operator becomes part of the URL, so you don't have the problem.

As for why things were implemented the way they were, I don't think we will ever know other than to say that both Views and DateTime were non-core modules before Drupal 8, and a lot of features were straight ports and relatively unchanged from Drupal 5.

Discussed this with @dawehner and it's very unlikely to happen for core 8.0.0, so we should probably move it to the Date contrib module and try to bring it into core in 8.1.

Still not 100% convinced this is needed, especially with the caching complications, but yeah, let's postpone for now.

I just came across this because I need a year based exposed filter. Should filters be covered in a different issue? In my opinion Views integration is incomplete if this is missing.

Just chiming in to say that filtering on year, month, and day separately would be great. In D7 this was possible by setting the granularity in the filter's settings. I am really missing that feature. Perhaps the Date module will finally handle this and get rolled into core.

+1 for caspervoogt's comment!!! Really missing the granularity feature!! Hope it gets added to core soon!

There is not reason to postpone this as far as I can tell. However, we are realling trying to move away from the do-it-all plugins in 8.x, and breaking things down into more manageable plugins. TBH, I need to review the IS and the plugins to assess where we stand with this.

I've never been quite clear on what this issue was about. From the IS:

but you can only use it to match exact dates.

This isn't accurate. The views integration went in with the same granularity that numeric dates receive from the Views module itself. Specifically, it provides individual date components (year, month, day), and some commonly used combinations (year & month for instance).

Here's the list of available arguments for a single field:

Marking as needing an IS update to clarify what would need to be done.

Maths comparison and date offset would be much more pertinent than string tools (begin with, string length).

Could date fields be managed as the publication date?
Filtering on publication date is ok.

Is it still required after #2786577: The Views integration Datetime Range fields should extend the views integration for regular Datetime fields?

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

I've just checked, and date comparison is now possible in Views. I've managed to filter a view with dates (either a publication date or a content date), with operators (>, <, etc.) on date offset (eg "-1 month") or YYYY-MM-DD.

I don't how long this is possible, but I can now replace my workarounds! ;-)

So, I think this issue can be closed.