[manarth]

TZs should be defined in the form "Europe/London", "Asia/Beirut", "Pacific/Auckland", etc.

Although the hour offset can change at extremely short notice (e.g. discontinuing Daylight Savings during Ramadan [1]), the timezone declaration (e.g. "Africa/Casablanca"), shouldn't need to change, just the underlying timezone database.

[1] https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocc...

[kseistrup]

That's not how I read TZSET(3). According to TZSET(3) you can either use (example for Copenhagen shown)

    TZ=CET

or

    TZ=:Europe/Copenhagen

but not

    TZ=Europe/Copenhagen

[manarth]

Apologies, I didn't explain my response very well.

You're totally right to say that in the context of TZSET, to load the timezone specification from a TZ-formatted file it needs to be prefixed with ':'.

Rather than saying "Technically, you should set the value of TZ to 'Europe/London'", I was trying to say that my philosophical opinion of timezone recording - whether in a CMS, on an O/S level, in a compiled app, etc - is that it should start with the standard of geographical location.

There might be occasions to augment that with other data, maybe including the UTC offset for that TZ at a particular time, but the TZ specification can be subject to frequent change, whilst a description such as "Europe/London" changes infrequently and seems to have the least ambiguity.

[kseistrup]

Ok, we agree then.