4 ms·
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
by 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 agotzset 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 agoOk, 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.