Hacker News new | ask | show | jobs
by phaemon 1959 days ago
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.
2 comments
treesprite82 1959 days ago
> 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.

link
phaemon 1959 days ago
> or fail noisily if it's not aware of that offset code.

But it is aware of it! You just told it, using the TZ variable, what EDT is. It's a timezone called EDT, with no offset from UTC!

If you wanted an offset, you should have written `TZ=EDT+4 date`

link
treesprite82 1959 days ago
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.

link
phaemon 1958 days ago
> 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.

link
treesprite82 1958 days ago
> 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.

link
steerablesafe 1959 days ago
why doesn't this work the same way for 'EST' then? You don't specify offset so it should just display in UTC as well, right?
link
phaemon 1958 days ago
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.

link
steerablesafe 1959 days ago
Various behaviors when requesting time in a non-existent timezone:

sane: report an error in some hard to ignore form

less sane: ignore the provided timezone, display the time in UTC and properly mark it with "UTC"

insane: ignore the provided timezone, display the time in UTC, but then mark it with the prefix of the provided timezone anyway.

I don't care how well documented the insane behavior is, it's still insane.

link
phaemon 1959 days ago
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.

link