4 ms·

> Let's take take a look, using the disastrously bad unix libc timezone tools It seems to me that the author did not initially read the documentation they link

> Let's take take a look, using the disastrously bad unix libc timezone tools It seems to me that the author did not initially read the documentation they linked to (https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...) and is now complaining in an annoying and entitled manner.

biggerfisch 6y ago
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"!
steerablesafe 6y ago
It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.
- phaemon 6y 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.
  - steerablesafe 6y 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.
    - phaemon 6y 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.
  - treesprite82 6y 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.
    - phaemon 6y 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`
      - treesprite82 6y 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.
        phaemon 6y 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.
        treesprite82 6y 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.
steerablesafe 6y ago
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.
- prussian 6y ago
  tzset manpage for glibc explains this: 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.
  - deleted 6y ago
    [deleted]
  - steerablesafe 6y ago
    Ok, so the key quote here: "If the colon is omitted each of the above TZ formats will be tried." So even if someone finds this sentence somehow this is still underspecified. The full logic seems to be for a TZ that doesn't start with ':' : 1. First format tried, if it fails... 2. ...interpret TZ as filespec, if it fails... 3. ...interpret TZ as std with offset 0. Note that there is fallback parsing of TZ that is not described at all (essentially 3rd and 4th formats), and two fallbacks, not one.

biggerfisch 6y ago

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"!

steerablesafe 6y ago

It's absolutely right to criticize insane behavior even if said behavior is documented. LOL "helpfully" being substituted to the output is absolutely insane.

phaemon 6y 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.
- steerablesafe 6y 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.
  - phaemon 6y 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.
- treesprite82 6y 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.
  - phaemon 6y 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`
    - treesprite82 6y 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.
      - phaemon 6y 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.
        treesprite82 6y 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.

steerablesafe 6y ago

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.

prussian 6y ago
tzset manpage for glibc explains this: 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.
- deleted 6y ago
  [deleted]
- steerablesafe 6y ago
  Ok, so the key quote here: "If the colon is omitted each of the above TZ formats will be tried." So even if someone finds this sentence somehow this is still underspecified. The full logic seems to be for a TZ that doesn't start with ':' : 1. First format tried, if it fails... 2. ...interpret TZ as filespec, if it fails... 3. ...interpret TZ as std with offset 0. Note that there is fallback parsing of TZ that is not described at all (essentially 3rd and 4th formats), and two fallbacks, not one.