Closed testower closed 1 year ago
As a curiosity, the example for v2.1 is Foo/Bar
, which of course is not valid.
@leonardehrenfried any thoughts?
When I added the timezones to the schema I got it originally from this list: https://nodatime.org/TimeZones?version=2022a&format=json
To me it seems that the canonical ones would be enough but since Java also understands the links/aliases, I would be ok with adding them. It will make the list significantly longer though.
I don't really have any strong opinions on this - but it would be nice the the spec and the schema agree, and a clarification on the spec is possibly what we need.
@mplsmitch Do you know the original intention of the spec here?
Way back in v1.0 we referenced the TZ database in the timezone
field definition.
https://github.com/MobilityData/gbfs/blob/v1.0/gbfs.md#system_informationjson
Starting with v2.0 we added type
to all fields and listed the defined field types where you will find:
Timezone - TZ timezone from the https://www.iana.org/time-zones. Timezone names never contain the space character but MAY contain an underscore. Refer to https://en.wikipedia.org/wiki/List_of_tz_zones for a list of valid values. Example: Asia/Tokyo, America/Los_Angeles or Africa/Cairo.
We've never formally supported links/aliases but it has come up in the past. The challenge with links/aliases at least here in the US is that we've got some really messy issues [1.] [2.]with Daylight Savings Time where the alias breaks down.
So it seems then that the spec and schema are in agreement, and it's just the example(s) that are wrong.
I don't reckon it's worth it to patch v2.2 just to fix that, so closing this. Thanks for the clarification!
Not sure if this is a problem with the schema or the spec, but posting it here first.
The example for v2.2 system_information as timezone
US/Central
which is not valid according to the schema.The spec says:
US/Central
is listed as being of TypeLink
, and links toAmerica/Chicago
, which is the canonical type.It seems then that either the list of timezones is incomplete, or the spec needs to specify explicitly that only canonical types are allowed.