Limits of Magento's automatic daylight‑saving adjustments for custom datetime attributes

Native Support for DST in Custom Attributes

Magento does not provide a native attribute flag or a configuration switch (such as an "is_timezone_aware" checkbox) that automatically enables DST-aware conversion for custom EAV datetime attributes. While core datetime fields are processed through the framework's timezone conversion layers, custom attributes are treated as raw data. If you store a value and render it without explicit conversion, it will not adjust for Daylight Saving Time (DST) transitions, leading to the common "off-by-one-hour" error.

The Technical Cause

Magento persists timestamps in UTC. The discrepancy occurs because the automatic conversion from UTC to the store's configured timezone is tied to specific rendering paths (like core UI components) rather than the attribute definition itself. If a custom attribute is rendered via a raw template or a custom API response, it bypasses the TimezoneInterface, displaying the UTC value or a fixed offset that does not account for the IANA timezone rules governing DST.

Recommended Upgrade-Safe Implementation

To ensure custom attributes respect DST without modifying core code, you must implement the conversion logic using Magento's built-in timezone services. This ensures that PHP's internal timezone database handles the transition rules automatically.

1. Persistence: Always convert local input to UTC before saving to the database. Use \Magento\Framework\Stdlib\DateTime\TimezoneInterface::convertConfigTimeToUtc().
2. Display: Use the TimezoneInterface::date() or formatDate() methods to convert the UTC value back to the store's configured timezone during rendering.
3. UI Components: For Admin grids and forms, ensure the field is declared as a date input within the UI Component XML; these components typically utilize the standard data providers that handle UTC-to-store-timezone conversion automatically.

Verification Steps

To verify that your implementation is DST-aware, perform the following tests:

• Database Audit: Save a value and check the database row to confirm the timestamp is stored in UTC, regardless of the store's local time.
• Boundary Testing: Set a date just before and just after a known DST transition (e.g., late March or October) and confirm the storefront display shifts the hour correctly.
• Zone Swap: Change the store timezone in Stores > Configuration > General > Locale Options to a different region and verify the custom attribute updates its display time accordingly.

Note: There are no official patches or first-party extensions that add this behavior globally to all custom attributes; the supported architectural pattern is the use of the TimezoneInterface.