[treesprite82]

If I'm understanding the examples, it looks like (in general) commands such as `TZ=EST date` work as expected (i.e. you can set offset just using the offset code).

> But it is aware of it! You just told it

The user didn't intend to. Defining a new offset code should be explicit, not a silent fall-back when it's unable to find EDT.

[phaemon]

> The user didn't intend to.

Well, they should have read the docs. They clearly show examples of how to define a timezone right there. It isn't a fallback, it's what TZ is for.

Edit: perhaps `date` should have a `-z --zoneinfo` option, in which you could specify a timezone by file and it would fail if the file did not exist. This would fix the issue and avoid breaking existing scripts.

[treesprite82]

> Well, they should have read the docs

You can say that about any bad design choice, and in this case I'd argue that the linked docs don't even agree with the behaviour. The syntax given by the docs for creating a new timezone requires explicitly specifying an offset (then optional stuff like daylight savings).

The quirk may be documented elsewhere, but before getting caught out by it the average user has no reason to be searching through multiple sources of documentation for an oddity they don't yet know exists.

> It isn't a fallback, it's what TZ is for.

If I'm understanding, `TZ=EDT` will search for an "EDT" timezone in its database, fail, then instead silently default to creating a new timezone with 0:00 offset. That's pretty much how I'd define a fall-back.