Summary
The SPXP specification states that timestamps are in UTC, but the examples and actual implementations use timestamps without the Z suffix (or +00:00), which can lead to ambiguity.
Current Behavior
The spec says timestamps are UTC, but examples show:
{
"seqts": "2018-09-17T14:04:27.373",
"createts": "2018-09-16T12:23:18.751"
}
Problem
Without an explicit timezone indicator, parsers may interpret these as local time:
// Ambiguous - could be parsed as local time
new Date('2018-09-17T14:04:27.373')
// Explicit UTC - no ambiguity
new Date('2018-09-17T14:04:27.373Z')
This can cause issues when:
- Clients are in different timezones
- Sorting posts chronologically
- Displaying "posted X hours ago" relative times
Suggestion
Clarify in the spec that timestamps:
- MUST be in UTC (already stated)
- SHOULD include the
Z suffix for ISO 8601 compliance
Example:
{
"seqts": "2018-09-17T14:04:27.373Z",
"createts": "2018-09-16T12:23:18.751Z"
}
Alternatively, explicitly state that the absence of a timezone indicator implies UTC, so client implementations know to handle it correctly.
References
Discovered while building a browser-based SPXP profile viewer.
Summary
The SPXP specification states that timestamps are in UTC, but the examples and actual implementations use timestamps without the
Zsuffix (or+00:00), which can lead to ambiguity.Current Behavior
The spec says timestamps are UTC, but examples show:
{ "seqts": "2018-09-17T14:04:27.373", "createts": "2018-09-16T12:23:18.751" }Problem
Without an explicit timezone indicator, parsers may interpret these as local time:
This can cause issues when:
Suggestion
Clarify in the spec that timestamps:
Zsuffix for ISO 8601 complianceExample:
{ "seqts": "2018-09-17T14:04:27.373Z", "createts": "2018-09-16T12:23:18.751Z" }Alternatively, explicitly state that the absence of a timezone indicator implies UTC, so client implementations know to handle it correctly.
References
ZDiscovered while building a browser-based SPXP profile viewer.