Eloquent date cast limits when app.timezone changes after naive timestamp storage

Laravel's Eloquent date casts serialize attributes to naive Y-m-d H:i:s strings by default, while config('app.timezone') supplies a single application-level default zone for Carbon instances. When that default zone is changed after rows have already been stored, existing database values are not automatically converted; instead, they are reinterpreted in the context of the new default. Because Laravel does not provide a built-in per-request user timezone context for model dates, teams must choose between storing UTC and converting at the edges or storing local civil time and accepting the ambiguity that comes with it.

Named IANA zones handle daylight saving time rules from the tz database, but naive local strings recorded near DST transitions can represent two distinct instants or none at all. Without offset-bearing storage, the framework cannot distinguish whether a stored value was meant as an absolute moment or a wall-clock time. This leaves an unresolved design decision about how model dates should behave when the application default or a user's regional zone shifts.

Should existing naive datetime columns be treated as immutable civil times or as zone-relative values that move when app.timezone changes? What is the supported boundary for converting user input to the storage zone when the column has no offset? How should ambiguous local strings during DST transitions be resolved when the user zone differs from the application default?