GBFS' reference - timezones: clarifications needed on deprecated/link/aliases time zones

[Oxalin]

Hi. I've been encountering some GBFS feeds containing non canonical timezones, i.e. America/Montreal (from àVélo Québec and from Bixi Montréal). GBFS' reference v3.0 points to the Wiki tz database time zones website, which lists canonical time zones along with links/aliases AND time zones that were canonical but deprecated (now being links). GBFS' reference doesn't specify if links/aliases are supported.

As you probably know, the IANA provides a list of canonical time zones. It also maintains a backward file containing deprecated time zones and aliases. This file suggests to include the list for compatibility reasons.

The Canonical GBFS validator schemas enumerate the values supported by the validator for different spec versions. Since it is the Canonical GBFS validator, I would expect the lists to only contain canonical values or, otherwise, to accept all the values including the one in the backward list (which isn't the case for any of these situations). Values like "CST6CDT" that are links (deprecated from canonical time zones) can still be found in the schemas.

This situation creates confusion and raises questions:

• Should the Canonical validator only validate timezone values that are canonical at the time of the release of the specs? If so, non canonical values should be removed.
• Should deprecated canonical values be supported? This list can change yearly for political reasons and users may end up expecting a timezone value that was canonical to still be present. Not all developers are following the latest list and some applications generating GBFS feeds may not be updated.
• Should links/aliases that have never been canonical be supported?
• Why would a some deprecated/link timezones be valid ("CST6CDT" for example), but not others? How is this decided?
• How should the specifications clarify this situation?

[leonardehrenfried]

I can answer one question since I added the list in the first place in 2022. I added what was the current list of time zones from this URL: https://nodatime.org/TimeZones?version=2022b&format=json

Back then CST6CDT seems to have been a canonical one but this has changed since.

I'm in favour of updating the list but against including links/aliases since library support is weak. (Actually for this point I need to make a 2024 research update, maybe things changed)

The validator will help feed producers to figure out what the correct values will be and fixes are easy: change America/Montreal to America/Toronto.

[testower]

A bit on the side: Let's not get confused by the usage of the term "canonical" in the validator. It has nothing to do with "canonical timezones".

[Oxalin]

I'm in favour of updating the list but against including links/aliases since library support is weak. (Actually for this point I need to make a 2024 research update, maybe things changed)

So, what I understand is that the references don't tell us if links/aliases should be supported or not, is that right? I'm mostly concerned about cases where canonical timezones become deprecated, but are still being used for some time (not every app will/can be updated out there).

Usecase: OpenTripPlanner doesn't support non canonical timezones because it relies on MobilityData's gbfs-json-schema as an "official" supported timezone list by the GBFS specs. OTP uses Java, which relies on IANA's db for its timezone support, where some links/aliases were supported by the past (I don't know if they still use the recommended backward compatible list). In the last few months at least, a few GBFS feeds with links/aliases were caught and were considered invalid because of the timezone. The dev team is considering supporting aliases/links if the specs allows it.

I'm myself dealing with two GBFS feeds in Québec where the timezone was set as America/Montreal (a canonical timezone deprecated in the last decade... which could be restored in the political context). If only canonical timezones are to be supported (the canonical list at the time of releasing a new version of the GBFS specifications), it is not a problem to contact the two sources to have them fix the feeds. However, I'm not the only one that encountered this situation, which means many other feeds maybe in the same situation.

[leonardehrenfried]

To add a data point, this is the list of time zones that my Java installation (Adoptium Java 21) knows about: https://gist.github.com/leonardehrenfried/d4b91813f42df8dc4cfcac161add6fcc

[richfab]

Thank you @Oxalin for raising this issue and @leonardehrenfried and @testower for the helpful info 🙏

Indeed, the schemas don't match the spec currently for the allowed timezones. The spec indicates: "Refer to https://en.wikipedia.org/wiki/List_of_tz_zones for a list of valid values" but the schemas don't contain all the values ​​from the list (e.g. 'America/Montreal' which used to be a canonical value but became a link to 'America/Toronto').

As a first step, I would suggest updating the schemas to match the spec. To do this, I propose replacing the timezones in the schemas with the content of the TZ identifier column from this list. This way, 'America/Montreal' will be considered valid by the validation tools (validator and schemas). I will do it in 7 days, unless someone objects.

Next, I would suggest everyone to provide their opinion by commenting on this issue on what the spec should or should not allow for timezones so that there is no more ambiguity. Please try to include use-cases and explanations to justify your opinion.

Thank you in advance!

[leonardehrenfried]

I was quite sure that back then we decided quite consciously that we don't want the links in the schema but I cannot find any trace of such a conversation so I must be imagining it. 😱

Also, I tried a few links and couldn't find any that my Java installation did not understand. For that reason I'm dropping my opposition to including the links in the schema.

[mobilitydataio]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[testower]

This issue can probably be closed now ?

[richfab]

I will close this issue on February 11, 2025 if there is no other comment.
Thank you @testower!

[richfab]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.