jhofstee
commented
5 years ago Perhaps not, I have never looked into this. Do you have better ideas?
Open mansr opened 5 years ago
jhofstee
commented
5 years ago Perhaps not, I have never looked into this. Do you have better ideas?
izak
commented
4 years ago Additional time zone issue received via level3 support: There is no timezone for Christmas Island.
mpvader
commented
1 year ago Update: started to discuss this with Qinetic, on Slack, https://victrondevelopment.slack.com/archives/C020QG3JVEW/p1679668146726119
idea being to have Qinetic fix this in gui-v2, and leave current gui as it is.
askpatrickw
commented
1 year ago If you have not already, have a look at the IANA's data https://www.iana.org/time-zones
mpvader
commented
1 year ago thanks!
chriadam
commented
1 year ago Those windowsZones.xml mentioned in the original comment are the ones which are in the Windows timezone backend.
If you build a Qt-based application for Windows and use QTimeZone to enumerate the available timezones, you will see ones which match those (i.e. the display name will be "E. Australia Standard Time", rather than "Australian Eastern Standard Time" as it will appear on Linux / IANA timezone-db backed systems). Similarly, the "abbreviation" you get from the Windows database is different (or nonexistent), whereas you will get e.g. "AEST" on timezone-db backed systems.
(FWIW, for Christmas Island, the timezone is actually under the Indian region, i.e. "Indian/Christmas", even though Christmas Island is an external territory of Australia.)
The timezone abbreviations mentioned by the customer are catalogued in the (IANA/Olson) timezone-db. Each timezone catalogued in the timezone-db has rules which define when observance of daylight savings time started (and possibly stopped), and which periods of the year daylight savings time applies. If a specified datetime matches the rule, the timezone will be either standard (%s = S) or daylight (%s = D) variation. Rules are given an identifier, e.g. AQ, Holiday, AN, AS etc.
Take these for example:
Zone Australia/Brisbane GMT+10:00 AQ AE%sT Zone Australia/Lindeman GMT+10:00 Holiday AE%sT Zone Australia/Sydney GMT+10:00 AN AE%sT Zone Australia/Adelaide GMT+09:30 AS AC%sT Zone Australia/Broken_Hill GMT+09:30 AS AC%sT
Australia/Brisbane observed daylight savings time from 1971 until 1992, so for dates between 1971 and 1992 which fell between October and February the timezone offset abbreviation was AEDT, but aside from that the timezone offset abbreviation is AEST. Australia/Lindeman observed daylight savings time for two more years (until 1994), but otherwise is identical to Australia/Brisbane. Australia/Sydney continues to observe daylight savings time, thus depending on the specific date a person in Sydney timezone has a timezone offset abbreviation of either AEDT or AEST. Australia/Adelaide continues to observe daylight savings time, with a base UTC offset of GMT+09:30, thus depending on the specific date a person in Adelaide timezone has a timezone offset abbreviation of either ACDT or ACST. Australia/Broken_Hill used to observe daylight savings time according to the same rules as Australia/Sydney (although with a different base-offset), but (since 2000) it now observes daylight savings time according to the same rules as Australia/Adelaide.
The IANA timezone-db is thus able to determine which UTC offset applied for a person in a particular timezone at a particular (historical or current) datetime. However, it contains "more information than necessary" if historical information is not important (e.g. Australia/Lindeman is, for all intents and purposes, identical to Australia/Brisbane for all current+future datetimes; and Australia/Broken_Hill is, for all intents and purposes, identical to Australia/Adelaide for all current+future datetimes). As such, I'm not entirely convinced that it makes sense to include ALL possible timezones from the timezone-db if some of them are of historical interest only. But I don't know enough about the topic to be certain...
One point to note: currently, timezone-db isn't shipped with Qt For WebAssembly and so my understanding is that apps running there only know about two timezones: UTC, and the current local timezone (which is exposed into the js context by the browser itself). See https://bugreports.qt.io/browse/QTBUG-91441 for more information.
chriadam
commented
1 year ago Update: started to discuss this with Qinetic, on Slack, https://victrondevelopment.slack.com/archives/C020QG3JVEW/p1679668146726119
idea being to have Qinetic fix this in gui-v2, and leave current gui as it is.
After some thought bubbling, I think it might be worthwhile putting timezone enumeration into venus-platform, see https://github.com/victronenergy/gui-v2/issues/299#issuecomment-1506483721 for some context.
mpvader
commented
1 year ago Understood.
Setting the time zone should for sure be done via venus-platform indeed.
But for getting the list I'm not so sure if doing that over venus-platform is a good idea. It would mean transferring all available timezones over dbus or mqtt. Quite an overkill for a large and completely static list. It can just as well be done compile time.
Needed info in the gui is:
Venus OS seems to get it here: https://github.com/victronenergy/openembedded-core/tree/dunfell_venus/meta/recipes-extended/timezone.
@mansr any thoughts on this, ie you also agree that somehow we should be doing this compile time? Either one time building a list out of that tz database and adding that to gui code; or doing that at compile time of the gui.
Ps for my self a few screenshots on how the current menu looks like:
A user reports that the time zone names for Australia are incorrect:
The selections in the GUI are based on a list from the Unicode Consortium: https://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml Evidently, this list disagrees with the names actual Australians use.
The grouping in the menus has caused past problems when countries have changed time zones (https://github.com/victronenergy/venus/issues/392). Perhaps using that list wasn't such a good idea.