It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.
No it isn't. If you tell your computer that the timezone your machine is set to is called "LOL", then of course that's what it should report. What else would it do?
It truncated the name because of the underscores, but you can do `TZ=somerandomthing date` to see it just reports what you say it is.
> If you tell your computer that the timezone your machine is set to is called "LOL", then of course that's what it should report. What else would it do?
If `TZ=EST date` adjusts the offset to EST, then a reasonable person would expect `TZ=EDT date` to either adjust the offset to EDT, or fail noisily if it's not aware of that offset code.
At a skim through the documentation I don't see anything warning about it's current behaviour.
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.
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.
Because it has additional information in a file in `/usr/share/zoneinfo`.
But you can still define a brand new timezone with the TZ variable. Perhaps you want to argue that you shouldn't be able to, but that's what it's for, as the document linked above clearly states.
It didn't display the time in UTC, it displayed the time in timezone LOL. It happened to be the same as UTC because no offset was specified. It knew it was timezone LOL because that's what the TZ variable was set to.
If you set your machine to something weird, then expect the utility that reports on those settings to report the weird settings you set.
Not defending/attacking the phrase "disastrously bad", but I'm not sure its a fair argument to say "the docs explain it", if the behavior isn't what a "reasonable" person would expect. Writing software that deletes your files (when you expect, say, the weather report) isn't excused if they write in the docs "oh this weather software randomly deletes files for no reason".
In this specific case though, even those docs do not explain what happens if the value is "invalid"!
Let's pick apart that documentation and the actual behavior, shall we?
By the documentation "EST", "EDT" and "America/Los_Angeles" are not valid TZ environment variable values, as none of them matches any of the formats. offset doesn't seem to be optional, and within offset hours are not optional.
Ok, maybe it is too pedantic, a permissive implementation can interpret no offset as 0, right? But that's not what happens here. The implementation looks up the timezone by the provided name somewhere, and only when it doesn't find it it falls back to 0 as an offset.
This lookup behavior doesn't seem to be documented on that page. It's not described in the GNU date man page either even though it uses TZ='America/Los_Angeles' as an example.
If the file specification filespec is omitted, or its value cannot be interpreted, then Coordi‐
nated Universal Time (UTC) is used. If filespec is given, it specifies another tzfile(5)-format
file to read the timezone information from. If filespec does not begin with a '/', the file
specification is relative to the system timezone directory. If the colon is omitted each of the
above TZ formats will be tried.