JMSSerializerBundle
JMSSerializerBundle copied to clipboard
Default timezone is determined only at build time
I had to troubleshoot weird behavior where different environments with identically configured timezone yielded different results when deserializing dates. Explicitly setting default_timezone in the bundle configuration fixed the issue. According to the documentation this value is supposed to default to PHP's timezone:
default_timezone: "UTC" # defaults to whatever timezone set in php.ini or via date_default_timezone_set
It turns out that the configuration class calls date_default_timezone_get() to get a default value which is then injected into the DateHandler, meaning that the timezone defaults to the timezone of the environment where the container was built (in my case one of the build servers had a different timezone) rather than the actual runtime environment.
This behavior should either be documented much more clearly or - if possible from a backwards compatibility standpoint - changed so that date_default_timezone_get() is called at runtime.
If your timezone changes at runtime, what about having an environment variable?
It doesn't actually change at runtime and hardcoding the value in the bundle config is a perfectly acceptable fix. I was just confused that date_default_timezone_get() is only called when the container is being built (which in my case happens on a build server) and not in the environment it's actually running in.
If this works as intended I still think it would be a good idea to explicitly mention this in the documentation in case somebody else is experiencing the same issue.
If you build your application on a build server, any symfony container related parameter has this issue. This is because symfony compiles the whole container and dumps it to file.
I understand that timezones are something that might challenge more often between servers... But here the whole container is affected
Exactly, which is why it caught me by surprise :) I assumed that default_timezone would default to null and that something (a service factory or the constructor of DateHandler for instance) would call date_default_timezone_get() at runtime in this case. At least the documentation made it sound that way. I just wanted to let you know that this behavior confused me and might also confuse others.