Timestamp validation

[richfab]

What is the issue and why is it an issue?

Currently, the validator accepts last_updated datetimes that are in the future and it accepts end datetimes that are before the start datetime. This could be an issue for consuming applications.

In #106, validating Timestamps was proposed using imperative rules (in JavaScript). However, using schemas and patched schemas instead, would have the benefit of having the validation done by ajv and all the results as an output of ajv.

Please describe some potential solutions you have considered (even if they aren’t related to GBFS).

The format of Timestamp changed from POSIX to RFC3339 in MobilityData/gbfs#522 so we should use 2 different validation methods:

1. RFC3339 Timestamps (>= v3.0-RC) could be validated using ajv #formatMinimum/formatMaximum.
2. POSIX Timestamps (<= v2.3) could be validated using JSON Schema patching #Range.

We must make sure that we compare using the same timezones.

Timestamp fields that MUST NOT be in the future (ERROR)

- every file with last_updated field
- station_status.json#stations.last_reported
- vehicle_status.json#vehicles.last_reported
- system_alerts.json#alerts.last_updated
- system_information.json#terms_last_updated
- system_information.json#privacy_last_updated

Timestamp fields that SHOULD NOT be greater than 5 minutes ago (WARNING)

- every file with last_updated field

Some Timestamp fields have a dependency (end >= start) which could be validated using ajv $data reference:

Timestamp fields with a dependency (ERROR)

- geofencing_zones.json#geofencing_zones.features.properties.end (>= start)
- system_alerts.json#alerts.end (>= start)

Implementation

1. Let's use this issue to align on the validation pattern.
2. Anyone, feel free to assign yourself if you are interested in doing the implementation.
3. If no one from the community has the bandwidth, it's ok! MobilityData will include this feature in its engineering prioritization.
4. Thank you all for your many great contributions already!