Timestamp fields like "updatedAt" are represented in the JSONAPI attributes in ISO 8601 format. But you cannot echo this same format back into a filter value.
For example, given the content:
{
"type": "recipes",
"id": "455f52e3-212e-4af7-b46a-55d8b93229a7",
"attributes": {
...
"updatedAt": "2017-07-22T09:00:14+0200"
...
}
}
this filter (which represents updatedAt < 2017-07-23T00:00:00+0200) does not match:
http://live-contentacms.pantheonsite.io/api/recipes?filter%5BupdatedAt%5D%5Bvalue%5D=2017-07-23T00%3A00%3A00%200200&filter%5BupdatedAt%5D%5Boperator%5D=%3C
Whereas if I convert the date to a unix timestamp, it matches:
http://live-contentacms.pantheonsite.io/api/recipes?filter%5BupdatedAt%5D%5Bvalue%5D=1500760800&filter%5BupdatedAt%5D%5Boperator%5D=%3C
For consistency, I suspect filter values should pass through the same format conversion that is used for attributes during a POST or PATCH.
Comments
Comment #2
ef4 commentedI just realized this may be caused by JSONAPI Extras, because I'm using the default Contenta install. This may actually be an issue with that module, not jsonapi proper.
Comment #3
wim leersThis is definitely related to #2860350: Document why JSON API only supports @DataType-level normalizers. But it's something that we'll need to revisit after that is fixed, depending on how much test coverage is added to #2860350: Document why JSON API only supports @DataType-level normalizers.
Comment #4
wim leersComment #5
wim leersActually, this is not related to #2860350: Document why JSON API only supports @DataType-level normalizers as directly as #3 suggests. It's the same "topic area" though (timestamp fields).
But the real problem here is how the concept of
@ResourceFieldEnhancerplugins aren't applied consistently by the JSON API module.Therefore this isn't blocked.
Comment #6
wim leersApparently
\Drupal\jsonapi_extras\Annotation\ResourceFieldEnhanceris a JSON API Extras-only concept! Moving there.Comment #7
wim leers