Skip to content

[Serializer] Allow custom timezone in DateTimeNormalizer during denormalization #59807

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
frankdekker opened this issue Feb 18, 2025 · 0 comments · May be fixed by #60153
Open

[Serializer] Allow custom timezone in DateTimeNormalizer during denormalization #59807

frankdekker opened this issue Feb 18, 2025 · 0 comments · May be fixed by #60153

Comments

@frankdekker
Copy link

frankdekker commented Feb 18, 2025

Description

I am using an API which returns a json response with dates according to format: RFC3339.

Example json response with date in UTC timezone:

{"orderDate":"2025-01-01T12:12:12+00:00"}

An example model I denormalize to:

class Order {
    #[Context([DateTimeNormalizer::TIMEZONE_KEY => 'Europe/Amsterdam'])]
    public DateTimeImmutable $orderDate;
}

The problem:

The DateTimeNormalizer nicely denormalizes this to my Order object with orderDate as DateTimeImmutable class. However my expectation was that the DateTimeImmutable had the timezone Europe/Amsterdam instead of UTC.

After a bit of digging I found out that inside the DateTimeNormalizer the following is executed during denormalization:

DateTimeImmutable::createFromFormat(\DateTimeInterface::RFC3339, "2025-01-01T12:12:12+00:00", new DateTimeZone('Europe/Amsterdam'));

This creates a DateTimeImmutable object in the timezone of the date-string and ignores the specified timezone. From the php.net documentation this is expected behaviour. However from the available normalization options this was a bit confusing.

The solution ( ? )

After some more researching I found this closed issue #31232 and PR #31256 which seems to address this issue. The PR provides a key PRESERVE_CONTEXT_TIMEZONE which sets the denormalized DateTime object to the timezone specified by the TIMEZONE_KEY. However this PR seems to be closed with the comment: "5.1 provides more flexibility", but I can't really find a solution to my problem.

Any objections again if I create a similar PR which adds the PRESERVE_CONTEXT_TIMEZONE context key?

Example

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants