Laravel Timezone Handling: UTC, Users, and DST Bugs

The First Rule: UTC in Storage and Application Runtime

If you set your Laravel application timezone to anything other than UTC in config/app.php, you're inviting chaos. I learned this the hard way on a production billing system where subscriptions renewed at midnight local time. The application server ran on America/Chicago time. When we expanded to European clients, database timestamp comparisons began failing because Carbon parsed local inputs while the MySQL database engine interpreted query parameters under its own UTC session setting.

Always keep config('app.timezone') set strictly to 'UTC'. Make sure your database connection in config/database.php enforces UTC as well. In PostgreSQL, use TIMESTAMP WITH TIME ZONE (timestamptz). In MySQL, standard TIMESTAMP columns automatically convert inputs from the current session timezone into UTC for storage, then convert back upon retrieval. If your database connection session timezone doesn't match Laravel's application setting, MySQL shifts your timestamps on every query.

Explicitly set 'timezone' => '+00:00' inside your MySQL array inside config/database.php to guarantee session consistency regardless of server defaults.

Handling Per-User Timezones Safely

Never call date_default_timezone_set() inside a request lifecycle or middleware to shift application runtime to match the authenticated user's timezone. In persistent PHP environments like Laravel Octane or when processing queue workers with php artisan queue:work, mutating global PHP runtime state alters every subsequent job or HTTP request handled by that worker process.

Keep application runtime strictly UTC. Handle timezone shifts explicitly when rendering views or preparing database query parameters.

Store a valid IANA timezone string on your users table, like Europe/London or America/Los_Angeles. Avoid non-standard three-letter abbreviations like PST or EST because they don't account for Daylight Saving Time rules and aren't unique across geographic regions.

Here is how to calculate date boundaries cleanly in Eloquent when a user searches for records created on a specific local calendar date:

use App\Models\Order;    
use App\Models\User;    
use Carbon\Carbon;    
use Illuminate\Database\Eloquent\Builder;    
    
public function getOrdersForUserDate(User $user, string $localDateInput): Builder    
{    
    // $localDateInput = '2026-03-30'    
    // Convert local start and end of day into UTC bounds for DB lookup    
    $startOfDay = Carbon::createFromFormat('Y-m-d', $localDateInput, $user->timezone)    
        ->startOfDay()    
        ->setTimezone('UTC');    
    
    $endOfDay = Carbon::createFromFormat('Y-m-d', $localDateInput, $user->timezone)    
        ->endOfDay()    
        ->setTimezone('UTC');    
    
    return Order::where('user_id', $user->id)    
        ->whereBetween('created_at', [$startOfDay, $endOfDay]);    
}

Notice that we avoid using raw SQL functions like WHERE DATE(CONVERT_TZ(created_at, '+00:00', '-04:00')) = '2026-03-30'. Wrapping indexed database columns in conversion functions prevents MySQL and PostgreSQL from using indexes on created_at, turning fast range scans into full table scans. Shift query boundaries inside PHP first, then execute a standard indexed range query.

The Twice-Yearly DST Traps

Daylight Saving Time transitions cause subtle bugs that lie dormant for months before surfacing twice a year. The most common mistake is assuming every calendar day has exactly 24 hours.

When spring forward occurs, local day length drops to 23 hours. When fall back occurs, local day length expands to 25 hours. If you add 24 hours to a Carbon instance set to a local timezone, you can jump an extra hour or end up on the exact same wall-clock hour the next day depending on how offset shifts get applied.

Consider Carbon 3 behavior in PHP 8.3:

// March 8, 2026 is the US Spring Forward transition day    
$dt = Carbon::parse('2026-03-08 01:30:00', 'America/New_York');    
    
// Adding 24 exact hours moves absolute time forward 86,400 seconds    
$plus24Hours = $dt->copy()->addHours(24);     
// Output: 2026-03-09 02:30:00 (EDT) because 02:00 was skipped on the 8th!    
    
// Adding 1 calendar day preserves human wall-clock time    
$plusOneDay = $dt->copy()->addDay();     
// Output: 2026-03-09 01:30:00 (EDT)

When generating daily reporting schedules or calculating user-facing renewal dates, use addDay() or addDays(). Use addHours(24) or addSeconds(86400) only when measuring fixed physical durations, like API rate limit windows or token expiration times.

In Laravel 12's task scheduler, pass the targeted user timezone to scheduled tasks so the framework handles DST adjustments automatically:

$schedule->command('reports:send')    
    ->dailyAt('08:00')    
    ->timezone('America/New_York');

Formatting Dates for Next.js and React Frontends

When building API endpoints for Next.js 16 and React 19 client components, send raw ISO 8601 UTC strings over JSON. Let the browser format the date using native browser APIs or user preferences.

In your Laravel Eloquent model or API Resource, format timestamps explicitly to include milliseconds and UTC timezone designators:

protected function casts(): array    
{    
    return [    
        'created_at' => 'datetime:Y-m-d\TH:i:s.v\Z',    
    ];    
}

Inside your React 19 client component, avoid hydration errors between server render and client render by handling timezone conversions cleanly with native JavaScript APIs:

'use client';    
    
import { useMemo } from 'react';    
    
interface FormattedDateProps {    
  isoString: string;    
  timeZone?: string;    
}    
    
export function FormattedDate({ isoString, timeZone }: FormattedDateProps) {    
  const formatted = useMemo(() => {    
    if (!isoString) return '';    
        
    const date = new Date(isoString);    
    const targetZone = timeZone || Intl.DateTimeFormat().resolvedOptions().timeZone;    
    
    return new Intl.DateTimeFormat('en-US', {    
      dateStyle: 'medium',    
      timeStyle: 'short',    
      timeZone: targetZone,    
    }).format(date);    
  }, [isoString, timeZone]);    
    
  return <span>{formatted}</span>;    
}

Summary Rules

• Keep app.timezone set to UTC in Laravel configuration files.

• Explicitly enforce +00:00 connection timezones in config/database.php.

• Store user timezones as standard IANA strings like Europe/Paris.

• Calculate date query bounds in PHP using Carbon before hitting Eloquent to preserve index usage.

• Use addDay() for human calendar dates and addHours(24) for exact elapsed durations.