Invalid time zone exception when supplying unrecognized zone identifier

Error condition

When DateTime->new receives a time_zone argument that DateTime::TimeZone does not recognize, it throws an exception with the message Invalid time zone: …. The module does not fall back to the floating time zone in this case; the floating zone is used only when the parameter is explicitly set to floating or omitted entirely.

Constraints and uncertainty

The exception originates from DateTime::TimeZone’s attempt to load OS‑specific zoneinfo files (for example /usr/share/zoneinfo). On systems where those files are missing or unreadable, the same error is raised even for zone names that would be valid on a fully provisioned host. Meanwhile, a long‑standing design question remains open: whether DateTime should automatically map common abbreviations such as EST or PST to their corresponding offsets, a behavior that currently requires DateTime::TimeZone::Alias or external modules.

Version differences between DateTime 1.x and 2.x may affect lazy loading of zone data, and reliance on the OS zone database introduces portability concerns for containerized or minimal environments.

Open questions

• Should DateTime treat unrecognized abbreviations as a recoverable condition and attempt an offset mapping, or is the explicit exception the intended contract?
• What is the recommended strategy for applications that must run on systems with incomplete zoneinfo databases without catching the Invalid time zone exception?
• Is there a roadmap to make the floating‑zone fallback configurable when a supplied identifier fails to resolve?