4 ms·
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.
by manarth 10y ago
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_Morocco https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocc...
- kseistrup 10y agoThat'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 10y agoApologies, 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 10y agoOk, we agree then.