Should the APL DATETIME type include explicit time‑zone metadata?

The goal is to decide whether the built‑in DATETIME scalar in Dyalog APL should carry time‑zone information so that conversions between regions can be performed without relying on external extensions.

Currently DATETIME stores a local‑time value without any offset, which forces projects to adopt ad‑hoc solutions such as storing UTC offsets separately or using third‑party libraries, leading to inconsistent handling of daylight‑saving changes.

What are the implications for existing code if DATETIME gains a timezone field? How would timezone‑aware DATETIME interact with the existing DATE, TIME, and TIMESTAMP primitives? Should the timezone be stored as a numeric offset from UTC or as an IANA zone identifier?