DateTime objects are serialized as strings

[bpolaszek]

Currently, datetime objects are serialized as strings, i.e. 2023-11-29T00:00:00+00:00.
This prevents date fields from being filterable (by range).
Aren't they supposed to be serialized as unix timestamp (integers)?

As a workaround I did this:

use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Serializer\Annotation as Serializer;
use Symfony\Component\Serializer\Normalizer\DateTimeNormalizer;

class MyEntity {
    // ...
    
    #[ORM\Column(type: Types::DATE_IMMUTABLE, nullable: true)]
    #[Serializer\Context([DateTimeNormalizer::FORMAT_KEY => 'U'])]
    public ?DateTimeImmutable $releasedAt = null;
}

It works, except timestamps are rendered as strings, not integers.
To fix this, I created a custom DateTime normalizer:

use DateTimeInterface;
use Symfony\Component\Serializer\Normalizer\DateTimeNormalizer;
use Symfony\Component\Serializer\Normalizer\NormalizerInterface;

final readonly class UnixTimestampNormalizer implements NormalizerInterface
{
    public function __construct(
        private DateTimeNormalizer $normalizer = new DateTimeNormalizer(),
    ) {
    }

    public function normalize(mixed $object, string $format = null, array $context = []): int
    {
        return (int) $this->normalizer->normalize($object, $format, $context);
    }

    public function supportsNormalization(mixed $data, string $format = null, array $context = []): bool
    {
        return $data instanceof DateTimeInterface
            && 'U' === ($context[DateTimeNormalizer::FORMAT_KEY] ?? null);
    }
}

But this is a little tricky, it would be better if proper serializing could be done out of the box.

[norkunas]

Hey.
Could you open a PR with your fix? :)

[bpolaszek]

Seems a little hacky, plus it requires end user the knowledge of having to flag each DateTimeInterface property with
#[Serializer\Context([DateTimeNormalizer::FORMAT_KEY => 'U'])].

We could enforce that context configuration to avoid that, but this could conflict with other serializer usages, which prefer using DateTimeInterface::ATOM for serialization (typically, API-Platform projects).

Another solution would be to drop some arbitrary property in the context as early as possible, to tell the serializer that it's the bundle that requested the serialization. This way it would know that DateTimeInterface objects have to be normalized as unix timestamp integers.

Or, the ability to use a different serializer instance.

I'll try to have a look at this.

[norkunas]

I think we can add format key to the context in Meilisearch\Bundle\SearchableEntity::getSearchableArray without breaking anything 🤔

[bpolaszek]

I think we can add format key to the context in Meilisearch\Bundle\SearchableEntity::getSearchableArray without breaking anything 🤔

Oh, didn't think about that, I just dropped #309 with a meilisearch: true context parameter. Might be useful in some other cases tho - WDYT?

[norkunas]

If meilisearch allows to store timestamps as strings then I'd go for directly configuring format without adding meilisearch to the context, but this needs to be tested then, otherwise current solution is the way to go 👍

[bpolaszek]

Nope, I already tested that, dates aren't searchable with date1 TO date2 filter when they're stored as a unix-timestamp strings - they have to be casted as integers, which is why I had to add a dedicated normalizer (otherwise using existing DateTimeNormalizer would have done the trick indeed)

[norkunas]

Sadly there is no way to configure DateTimeNormalizer to call getTimestamp instead of format('U') 😞