RFC 3339 vs ISO 8601 #26

edent commented 2026年03月18日 11:04:54 +01:00

This is minor pedantry.

Most Internet standards use RFC 3339 for timestamps. This is because ISO 8601 is a non-free standard; you have to pay quite a lot to be able to read it.

Given that human.json only uses YYYY-MM-DD, there's likely no problem swapping the standard. See https://ijmacd.github.io/rfc3339-iso8601/

This is minor pedantry. Most Internet standards use [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) for timestamps. This is because ISO 8601 is a non-free standard; you have to pay quite a lot to be able to read it. Given that human.json only uses YYYY-MM-DD, there's likely no problem swapping the standard. See https://ijmacd.github.io/rfc3339-iso8601/

robida commented 2026年03月19日 16:48:55 +01:00

Ah, I didn't know. Let's update the spec.

Ah, I didn't know. Let's update the spec.

bannmann commented 2026年03月21日 10:40:09 +01:00

Wholeheartedly agree on swapping the standard referenced by human.json!

As the comparison page linked by @edent hilariously shows, the ISO monster leaves a lot of choices to the application/spec using it. RFC 3339 improves on this, but it, too, does not strictly define one format: For its date-time format, the date and time can be separated by T or t. But one could also use a space, an underscore, @, or really anything, maybe even multiple characters. (Spec quote, emphasis mine: "Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.")

Therefore, for interoperability, please not just reference the RFC, but specify the concrete format that human.json uses. Here's my suggestion:

RFC 3339 _full-date_ when the vouch was made

Adding a time value (as @robida implies in #33) introduces a lot more variation, as suddenly an implementation would have to deal with parsing the various offset variants, and probably deal gracefully with people forgetting to include the offset. So I would recommend not going there, but if it's desired, my suggestion would be this:

RFC 3339 _full-date_ when the vouch was made, optionally followed by a space character and an RFC 3339 _full-time_.

Wholeheartedly agree on swapping the standard referenced by human.json! As the comparison page linked by @edent hilariously shows, the ISO monster leaves a lot of choices to the application/spec using it. RFC 3339 improves on this, but it, too, does not strictly define one format: For its `date-time` format, the date and time can be separated by `T` or `t`. But one could also use a space, an underscore, `@`, or really anything, maybe even multiple characters. ([Spec quote](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6), emphasis mine: "Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by **(say)** a space character.") Therefore, for interoperability, please not just reference the RFC, but specify the concrete format that human.json uses. Here's my suggestion: > `RFC 3339 _full-date_ when the vouch was made` Adding a time value (as @robida implies in #33) introduces a lot more variation, as suddenly an implementation would have to deal with parsing the various offset variants, and probably deal gracefully with people forgetting to include the offset. So I would recommend not going there, but if it's desired, my suggestion would be this: > `RFC 3339 _full-date_ when the vouch was made, optionally followed by a space character and an RFC 3339 _full-time_.`