@kellenmace ya, I actually think it would be better if the input was a timestamp instead of a day/month/year input like it is now.

Like, we could accept a timestamp as the input, and let the conversion happen behind the scenes via something like strtotime() or whatever.

I definitely think this would be valuable for a lot of folks.

Like, we could deprecate day, month, and year and introduce a timestamp field.

So the query could become:

dateQuery: {
        column: MODIFIED
        after: {
          timestamp: "2020-04-13T20:39:42+00:00"
        }
      }

or something like that.

We'd need to specify the format(s) allowed for input. The above example is ISO 8601, for example.

@jasonbahl Yeah, accepting a timestamp would work beautifully for me. 👍

@jasonbahl Just added a PR. Rather than a timestamp field nested inside of the DateQueryInput, I opted to remove DateQueryInput and have the before and after fields accept strtotime()-compatible strings. I did that for consistency with WP_Query(), since it accepts strings for the before and after args themselves. Docs: https://developer.wordpress.org/reference/classes/wp_query/#date-parameters. That way our 'dateQuery' => 'date_query' mapping still works as expected.

We had talked about throwing an error if a non-strtotime()-compatible string was provided, but it doesn't look like we're doing that for many of the other args. Like if you fire off a query like this:

posts(where: {in: [999999]}) {
    nodes {
      title
    }
  }

...and there is no post with an ID of 999999, no error is thrown. You just get back an empty nodes array. And the same is true for most other fields that ultimately get passed into WP_Query().

If a non-strtotime()-compatible string is passed into WP_Query() as the date query before or after arg, it simply gets ignored. So that's what is happening for WPGraphQL queries in this PR branch currently, as well. Please let me know if you think we should throw an error instead, though. Thanks.

P.S. Issue number 1234 FTW!

Dear All

It seams that there is no activity for more than one year on this topic.
I think this feature request will be very valuable. Are there any plans to continue or to merge the respective pull request.

Thank you in advance.
Kind regards.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had recent activity. If you believe this issue is still valid, please open a new issue and mark this as a related issue.

I think this issue shall not be ignored while it is also solved within a PR. This useful feature avoids inefficient calls and responses.

No worries @rgevrek this is still on the radar for v2, got closed by an overzealous 'stale-bot' 😅

sorry, but any updates on this? I really could use this feature...

Like, we could deprecate day, month, and year and introduce a timestamp field.

So the query could become:

dateQuery: {
        column: MODIFIED
        after: {
          timestamp: "2020-04-13T20:39:42+00:00"
        }
      }

or something like that.

We'd need to specify the format(s) allowed for input. The above example is ISO 8601, for example.

yes plsssssss 🙏

i need that!

looking forward to it

related: #1713