1. 16
  1.  

  2. 4

    man 3 tzname goes over that and here. TZ can have 2 strings, as a pair for timezones: the standard and the daylight saving. Also, daylight saving time is ambiguous in itself and depends on regional legal decisions. What you’re trying to represent is the current “civil time”. That’s why it’s preferable to use the name of a city, and not a timezone name or daylight saving timezone name.

    1. 2

      Old Plone had a bug, probably aince fixed, where it would try to round trip time zone names through these ambiguous abbreviations. I’m a little fuzzy on the details, something like: We had a site with the tz set to Sydney, which is Australian “EST”. It would product a DateTime (not datetime) object which was adjusted for the +12 timezone, then later something would reinterpret that as if it were adjusted for +7 because that was (American) “EST”. This lead to the site trying to send emails with date headers in the future, which made all MTAs reject them. We papered over the problem by making an “AEST” abbreviation which didn’t collide.

      1. 2

        Indeed, I think most systems do use AEST/AEDT these days for our time zones these days.

      2. 1

        While unfortunate, I don’t think this is the appropriate way to describe this. Many of the libc tz* functions describe how it works and also describe in cases of error, it tries to fit the value to a tz database entry or it uses an offset of 0 with no DST. I imagine there was probably plenty of legacy behaviors that had to be replicated. Keep in mind, even functions like tzset have a type-signature of void tzset() and doesn’t set errno so I’m not sure what the author expects in terms of handling cases where TZ is gibberish.

        Interesting fact as well: You can get a valid tz environment variable from the timezone database file with tail. I know this because at work someone was doing it and I had to fix it.

        tail -1 /usr/share/zoneinfo/America/New_York

        More edits:

        Wait til the author sees timezones like Turkey, where the abbreviations have been removed for numeric offsets <+3> I think? Some older versions of tic and older platforms may not be so happy with them. IANA won’t be using made up abbreviations moving forward as far as I know.