Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR clarifies the behavior of timestamp columns in relation to date/datetime casting and timezone handling in Laravel.
Key points:
This update is related to [10.x] Explain UTC behaviour when serialising dates #9287 and Serializing datetimes with custom format won't use the Carbon instance inner timezone. framework#49899.
While the referenced issues state that dates are always displayed in UTC regardless of custom formatting, this is not entirely accurate. For non-timestamp columns, Carbon instances are created based on the app.timezone configuration and formatted in local time, as per the original documentation.
However, for timestamp columns (created_at, updated_at), the timezone setting is lost during pre-casting processing (serializeDate, Date::parse, format methods), resulting in consistent UTC formatting.
This discrepancy can lead to confusion for developers who expect consistent behavior across all date columns with similar cast settings.
It's important to note that following the documentation's recommendation to keep app.timezone set to the default UTC value would prevent these inconsistencies.
Given the potential impact on many applications, we believe updating the documentation is preferable to modifying this core behavior.