The specification should require (or recommend) that RPDE Feed Implementers do not exceed signed 64-bit integers for modified
Why 64-bit?
Most languages have a native data type that supports integers to this size
Why "signed"?
While I haven't seen any examples of this in the wild, the RPDE spec does not specifically preclude the existence of negative timestamps.
Why?
To tie in with our recommendation that RPDE Feed CONSUMERS use a data types that supports at least signed 64-bit integers. This is documented in https://developer.openactive.io/using-data/harvesting-opportunity-data. See the detail there for a rationale of why 64 bits are required (summary: due to SQL Server's rowversion/timestamp)
The specification should require (or recommend) that RPDE Feed Implementers do not exceed signed 64-bit integers for
modifiedWhy 64-bit?
Most languages have a native data type that supports integers to this size
Why "signed"?
While I haven't seen any examples of this in the wild, the RPDE spec does not specifically preclude the existence of negative timestamps.
Why?
To tie in with our recommendation that RPDE Feed CONSUMERS use a data types that supports at least signed 64-bit integers. This is documented in https://developer.openactive.io/using-data/harvesting-opportunity-data. See the detail there for a rationale of why 64 bits are required (summary: due to SQL Server's
rowversion/timestamp)