We have multiple issues setting the default timezone via GENERIC_TIMEZONE env var:
everything we have tried thus far results in “Default Timezone not valid” in the timezone listings of workflow settings, including “Etc/GMT”, “Australia/Canberra”
the timezone listing is now in timezone name format, as opposed to timezone offset, which makes trying to find a specific timezone close to impossible, as it is not alphabetical. See image:
Previous (desired) format:
Etc/GMT does not even show in the list, despite what is shown above (dark image) - the only reason that Etc/GMT shows above, is that the specific workflow that the screenshot is taken from already had GMT +00:00 (Etc/GMT) set before the listings went to the format shown (dark image).
This was specifically changed because the offset isn’t fixed for all timezones, and we kept getting bug reports about the offsets being incorrect.
Also, the displayed offset wasn’t used anywhere at all, and was meant only to help find relevant timezone quicker.
So, for now we’ve switched to showing just the timezone names (like most other apps and operating systems do).
We’ll look into grouping these or using some other mechanism to make timezone selection easier in the UI.
I’ll check if this is a bug in the code. However, since we are literally copying over the raw timezone names from IANA time zones, it’s entirely possible that we are now missing some non-standard timezone names, and might have to augment the standard list from IANA.
Thank you for the response. If the offset could be added as a hint to the name at least, that would be handy.
I suppose there is an argument that typing the desired timezone by name will find the desired zone (doesn’t work for Etc/GMT, Etc/UTC, for some reason), but that will only work if the TZ in question is part of the list (as you mentioned), but if it doesn’t find it, then if the TZ at least has an offset hint, one would be at least able to use a fallback TZ (with same offset), if the specific one desired is not included.
I’ve found recently that in my case GENERIC_TIMEZONE=Australia/Brisbane works only when added directly via docker compose (with no quotes), but won’t work for some reason when using an env variable ( ie. ${TIMEZONE} ).
Checked typos and tested other timezones and got the same result, but not ruling out user error
Running self-hosted on the latest docker image, ubuntu 22 if that helps.
This package doesn’t suppor Etc options which is why they are not included, Looking at the list of timezone standards “Australia/Canberra” is not an official timezone and it is instead a link to “Australia/Sydney”.
“Australia/Brisbane” is a canonical timezone and is included in the data, Don’t use quotes when setting the timezone as that can also cause issues.
When you say you need Etc values can you share more information on that? We can of course look at adding them in as they are part of the IANA list but at the same time there is a published list of timezones and what they link to or if they are canonical which removes issues with deviations and it means you likely won’t need to remember to update your timezone which I would expect if you were usign Etc values.
A lot of focus for us is around UTC.
When I mentioned the Canberra timezone that was just another example that I would expect to work, even though it is non-canonical - it is still a linked TZ.
But it is not something that we cannot work around.
The UTC issue is something that cannot be worked around, and all new workflows can’t currently be set to UTC.
