Add display hint to output u64 as ISO8601 time

[justahero]

This PR implements #451.

The following log statement prints the given timestamp in milliseconds as a ISO8601 datetime without a timezone.

defmt::info!("Timestamp is {:iso8601ms}", 1618910624804);
// => "Timestamp is 2021-04-20T09:23:44.804Z"

Alternatively to log a u64 as a ISO8601 datetime in seconds use the :iso8601s display hint

defmt::info!("Timestamp is {:iso8601s}", 1618910624);
// => "Timestamp is 2021-04-20T09:23:44"

[japaric]

Implementation looks good to me! Thinking more about it, the + specifier is a bit cryptic and it would be hardcoded to milliseconds. One may want to specify the timestamp in microseconds or some other resolution. So, I think we may want to call this one iso8601ms to differentiate from other possible future display hints. Thoughts?

[Urhengulas]

[W]e may want to call this one iso8601ms to differentiate from other possible future display hints. Thoughts?

Is ms maybe enough? It seems more in line with the existing us (microseconds).

[justahero]

The + display hint was more a suggestion, we can change it to something more appropriate. Imho the iso8601ms hint is a bit long but compared to ms it's less ambiguous. Reading the latter type hint, it kind of signals the full number is represented instead of a datetime.

Adapting the display hint to iso8601ms also allows a representation based on seconds, e.g. iso8601s which might also be useful.

[Urhengulas]

Imho the iso8601ms hint is a bit long

My problem isn't actually the length, but I feel that it is rather cryptic. I definitely would need to look it up if I am seeing it in some elses code. And I would prefer "intuitiveness" over "shortness".

Other options I am thinking about are:

• time
• datetime
• timestamp

Or on the short side:

• t
• dt
• ts

But none of them seems really good.

[justahero]

@Urhengulas, from your list datetime seems the best choice as this is also defined in RFC 3339 to consists of a full-date (e.g. "2021-10-21") & full-time (e.g. "12:34:56.789").
In this regard ISO8601 is quite specific in its format, even though some components can be considered "optional" (e.g. fraction of a second or the time offset). My personal preference here is ISO8601, but I'm fine with other type hints as well.

[Urhengulas]

@Urhengulas, from your list datetime seems the best choice as this is also defined in RFC 3339 to consists of a full-date (e.g. "2021-10-21" & full-time (e.g. "12:34:56.789").
In this regard ISO8601 is quite specific in its format, even though some components can be considered "optional" (e.g. fraction of a second or the time offset). My personal preference here is ISO8601, but I'm fine with other type hints as well.

Just go with your preferred one, then 😁

[Urhengulas]

Looks really good!

[Urhengulas]

bors d+

[bors]

✌️ justahero can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

[justahero]

bors r+

[bors]

Build succeeded:

• ci