Regarding the second use-case with dates, I think a @Serializer\Context() annotation (and xml/yaml mapping equivalent) would do it. You would use it like this:

class Foo
{
    /**
     * @var \DateTime
     *
     * @Serializer\Context({
     *      DateTimeNormalizer::FORMAT_KEY = \DateTime:: RFC3339
     * })
     */
    public $date;
}

The annotation could accept a normalizationContext, denormalizationContext or both context at once (default option), and perhaps a traverse option to forward the context on deeper nodes if any.
Any normalizer with specific options would benefit from it, as it'll allow to configure anything on a per-case basis.

Regarding the second use-case with dates, I think a @Serializer\Context() annotation ... would do it.

To me that still feels like it's leaking the DateTimeNormalizer implementation; or any other context implementation. One of the benefits of custom annotations is that you get to hide your implementation neatly inside the annotation. Then if that implementation needs to change, however much so, you don't have to dig around updating all of your entities.

Sure, it does not aim to solve your custom annotations feature request, which is requiring you to write some custom code.

But it solves part of the described use-case and many others, by providing out-of-the-box a way to configure existing (de)normalizers on a per-case-basis. The context keys of these normalizers are part of their API, so it's not really "leaking implementation"; it provides a flexible way to configure it.

I don't disagree that it would be beneficial to be able to configure context on a per-field basis; I just didn't want my feature request to get lost to this new idea. Do you want me to create a new feature request for the Context annotation? Or would you be okay doing that yourself since it was your idea?

To me that still feels like it's leaking the DateTimeNormalizer implementation; or any other context implementation.

Sure, but you could build a custom annotation on top of that:

#[\Attribute]
class DateFormat extends Context
{
    public function __construct(string $format)
    {
        parent::__construct([
            DateTimeNormalizer::FORMAT_KEY => $format
        ]);
    }
}

Regarding the first use case, this would fit well in the new Encryption component by @Nyholm

#39344

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

Please keep this open