Lumen app.timezone configuration and database persistence consistency

Lumen timezone synchronization with MySQL sessions

Lumen retrieves the app.timezone configuration value and forwards it to the underlying PDO MySQL connection, which attempts to set the session timezone for the duration of the request. This alignment ensures that Carbon instances generated within the application layer produce dates that match the database's temporal interpretation during persistence and retrieval.

Likely explanation vs confirmed facts

1. When app.timezone is explicitly set, Lumen's bootstrapping code passes this value to PDO, which executes SET time_zone on the MySQL session, matching Carbon's internal timezone.
2. Confirmed: MySQL TIMESTAMP columns auto-convert to UTC on insert and revert to the session timezone on read. DATETIME columns store raw values without conversion. A mismatch between the application timezone and the MySQL session timezone produces offset shifts that appear as data inconsistency.
3. Runtime change risk: Altering app.timezone between request cycles resets Carbon's timezone but does not automatically re-sync the MySQL session timezone, especially on reconnect or persistent connections.

Recommended approach for alignment

1. Explicitly set the MySQL session timezone to config('app.timezone') at connection open, typically via a service provider or connector hook, rather than relying on implicit forwarding.
2. Avoid per-request date_default_timezone_set() calls unless absolutely necessary; prefer applying the timezone at the application bootstrap level.
3. If UTC storage is not required, use DATETIME columns and format dates in the application using Carbon's format() method with the configured timezone, rather than depending on MySQL's automatic conversion.
4. Ensure both app.timezone in Lumen config and PHP's date.timezone ini setting are defined, as Lumen falls back to the latter when the former is absent.

Verification steps (scoped, safe)

SELECT @@session.time_zone; -- Compare the output string to the value of config('app.timezone'). -- They must match for consistent TIMESTAMP handling.

$carbon = \Carbon\Carbon::now(); // no manual timezone set -- Confirm format() offset matches the expected app.timezone offset when persisted to and retrieved from a TIMESTAMP column.

$ts = \Carbon\Carbon::createFromFormat('Y-m-d H:i:s', '2026-10-11 21:12:43'); -- Persisted value: $ts->timestamp; -- Retrieve the row and compare the returned timestamp's offset to app.timezone.

Diagnostic needed: What is the current value of config('app.timezone') and what does SELECT @@session.time_zone return after a typical request? Providing these two values will determine whether the recommended explicit sync step is required or if the existing fallback behavior is sufficient.