Timezone scope limits for admin grids and cron boundaries in Magento

Answer

Admin order grids, report filters, and related UI components display dates using the store view’s timezone (resolved via Magento\Framework\Stdlib\DateTime\TimezoneInterface). Cron jobs, however, evaluate their schedule windows using the server’s system timezone as returned by PHP’s native date/time functions.

Confirmed facts

• Magento persists all datetime values in UTC.
• The admin grid’s date‑filter logic calls TimezoneInterface to convert UTC to the current store’s configured timezone before rendering.
• The core cron scheduler obtains the current time from PHP’s date()/time() functions, which respect the server’s date.timezone setting or the OS timezone; no store‑scoped conversion is applied.

Likely explanation

Because the admin interface is tied to a specific store scope (store view, website, or global), the framework deliberately uses that scope’s locale for user‑facing dates. Cron runs in a CLI context without a store request, so it falls back to the environment’s default timezone.

Verification steps (only needed if you suspect custom overrides)

1. Enable debug mode and inspect the SQL generated by an admin order grid date filter; the WHERE clause should contain a conversion like CONVERT_TZ(main_table.created_at, '+00:00', store offset).
2. Create a minimal cron task that logs date('Y-m-d H:i:s') to a file; compare the logged value with the output of date in the shell to confirm server‑timezone usage.
3. If you observe a different timezone in the admin grid, check for any plugins or preferences that replace TimezoneInterface.

If you have a custom module that modifies the timezone resolver, share the class name or configuration so the recommendation can be adjusted.