search

MobilityData / gbfs-json-schema

JSON Schema for GBFS feeds, managed by MobilityData. The versions are organized by folders. CC BY 4.0
Apache License 2.0
23 stars 25 forks source link

Invalid timezone (US/Central) #84

Closed testower closed 1 year ago

testower commented 1 year ago

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:

Refer to http://en.wikipedia.org/wiki/List_of_tz_zones for a list of valid values. Example: Asia/Tokyo, America/Los_Angeles or Africa/Cairo.

US/Central is listed as being of Type Link, and links to America/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.

testower commented 1 year ago

As a curiosity, the example for v2.1 is Foo/Bar, which of course is not valid.

testower commented 1 year ago

@leonardehrenfried any thoughts?

leonardehrenfried commented 1 year ago

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.

testower commented 1 year ago

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.

testower commented 1 year ago

@mplsmitch Do you know the original intention of the spec here?

mplsmitch commented 1 year ago

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.

testower commented 1 year ago

So it seems then that the spec and schema are in agreement, and it's just the example(s) that are wrong.

testower commented 1 year ago

I don't reckon it's worth it to patch v2.2 just to fix that, so closing this. Thanks for the clarification!