Add fractional second support to timestamps #8
Conversation
RFC-3339 supports fractional seconds as does the ISO-8601 but the regexp being used for validation of timestamp strings did not support it. Technically the [RFC-3339 specification](https://www.ietf.org/rfc/rfc3339.txt) allows use of a comma `,` as well as decimal point `.` for the whole and fractional seconds separator: > time-fraction = ("," / ".") 1*DIGIT Although use of `,` is common in European countries, in the interests of eliminating equivalent but lexically different encodings which would have a different cryptographic hash, this change only allows the decimal point as separator. Thus `2016-10-02T07:31:51.42Z` is a valid timestamp, but `2016-10-02T07:31:51,42Z` is not.
|
I see that this could cause an inconsistency with your pretty generate since the standard iso8601 output does not include fractional seconds so accuracy would be lost in parsing and generating TJSON again. A workaround might be a precision digit for the Another alternative would be to say you always output however many significant non-zero digits it takes to convey the fractional seconds part if it is non-zero. So if you're given timestamps without a fraction you don't output them with a decimal point for seconds. If has a fractional part you output as many digits as is necessary (I believe the accuracy is generally milli, micro or nanoseconds) but no more. A combination would be to do the default, but allow override with a precision digit. So if it is Despite all these potential issues I still think fractional second support is important for timestamps. There are so many uses where a second resolution just doesn't cut it. |
|
Note that the spec presently mandates Z-normalized RFC 3339 timestamps: https://www.tjson.org/spec/#rfc.section.3.4 Subsecond precision is not addressed in the spec, but should probably be allowed. If it is allowed it should be called out in the spec and added to the test cases. |
RFC-3339 supports fractional seconds as does the ISO-8601 but the regexp being used for validation of timestamp strings did not allow them for a TJSON timestamp value.
Technically the RFC-3339 specification allows use of a comma
,as well as decimal point.for the whole and fractional seconds separator:Although use of
,is common in European countries, in the interests of eliminating equivalent but lexically different encodings which would have a different cryptographic hash, this change only allows the decimal point as the separator. Thus2016-10-02T07:31:51.42Zis a valid timestamp, but2016-10-02T07:31:51,42Zis not.