TIMESTAMP vs DATETIME for regional time zone conversion

A MariaDB schema must handle event logging across multiple regional time zones while ensuring data remains consistent during daylight savings transitions. The goal is to maintain a reliable audit trail that can be retrieved in the local time of the event origin.

Two documented approaches exist: using TIMESTAMP columns, which automatically handle UTC conversion based on the session time zone, or using DATETIME columns combined with explicit CONVERT_TZ() calls and a separate time zone identifier column.

The primary constraint is the need for long-term data retention beyond the year 2038, contrasted with the requirement for automatic session-based offsets during retrieval.

• Does the automatic conversion of TIMESTAMP outweigh the risk of the 2038 epoch limit in long-term archival systems?
• Is the manual overhead of DATETIME and CONVERT_TZ() more sustainable for multi-regional reporting than managing session-level time_zone variables?