Invalid time zone exception when supplying unrecognized zone identifier

Question

Error conditionWhen 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 uncertaintyThe 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 questionsShould 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?

Siddharth · Answer

AnswerDateTime->new throws Invalid time zone: … when the supplied time_zone argument is not recognized by DateTime::TimeZone. There is no automatic fallback to the floating time zone. Floating is used only when time_zone is explicitly set to floating or omitted entirely.
Likely explanationThe exception originates from DateTime::TimeZone attempting to load OS-specific zoneinfo files, e.g. /usr/share/zoneinfo. On systems where those files are missing or unreadable, the same error is raised even for names that would be valid on a fully provisioned host. Abbreviations such as EST or PST are not resolved without DateTime::TimeZone::Alias or an external mapping.
Confirmed facts

DateTime->new throws "Invalid time zone: <identifier>" when the identifier is not known to DateTime::TimeZone.
The error arises from attempting to load OS-specific zoneinfo files; missing or unreadable files cause the exception even for valid names.
The floating time zone is only selected when the time_zone argument is explicitly "floating" or omitted entirely; otherwise no automatic fallback occurs.
Version differences between DateTime 1.x and 2.x can affect lazy loading of zone data, influencing when the exception is raised.

Steps to diagnose and address for this case

Verify recognized names on the host:
perl -MDateTime::TimeZone -e 'print join("
", DateTime::TimeZone->names())'
Check zoneinfo presence and readability:
ls -l /usr/share/zoneinfo/Region/City
If the zone file is absent, install tzdata or provide a complete zoneinfo tree for the deployment.
To avoid the exception, use an explicit floating zone:
DateTime->new( time_zone => "floating" )
For abbreviations, load DateTime::TimeZone::Alias or map the abbreviation to a canonical zone name before calling DateTime->new.

To choose the correct remediation, can you confirm the operating system and Perl/DateTime versions in use? That changes whether the issue is a missing zoneinfo database or a version-specific lazy-load behavior.

Invalid time zone exception when supplying unrecognized zone identifier

Error condition

Constraints and uncertainty

Open questions

1 answer

Answer

Likely explanation

Confirmed facts

Steps to diagnose and address for this case

Your perspective belongs here.

0 question comments