Add timesecond precision field for measurements

[ojousima]

Firmwares sending data at > 1 Hz rate can lead to mixed order of packets on poor network connections. Having the millisecond precision would solve this issue.

This is mostly relevant for MQTT data, one possibility is to add a field iso_time: 2022-09-12T09:55:40.378983Z

[Scrin]

I would prefer either millisecond or nanosecond int64 unix timestamps (even if the internal implementation doesn't offer this precise resolution). The reasoning is that this doesn't require any "date/time format parsing" in the consuming application, and the messages are technically not meant to be "directly consumed by humans", so having a human readable iso timestamp is of very little benefit.

[TheSomeMan]

We first need to decide on the format of the timestamps, so as not to break the client's custom software.
Maybe we should implement some configuration options in UI to select the format of timestamps

[Scrin]

I would suggest against making this configurable, since doing so would mean that "client applications" would need to implement support for every format in order to avoid interoperability problems if a user wants to use different pieces of software simultaneously

Since the MQTT data is not meant to be "directly consumed" by humans, any machine readable/parseable format with sufficient precision is fine, it's up to the client applications to decide how to format the timestamps for the end users

[markoaamunkajo]

@ojousima how do you see this feature, is it beneficial?
@TheSomeMan does this affect memory usage?

[ojousima]

I think this is a really edge case, I have hit this only when dealing with custom acceleration firmwares. It might make sense to just close this and live with the second precision.

[TheSomeMan]

I agree, this task does not make much sense for environmental sensors and HTTP(S) targets.
But for MQTT it does make sense to prevent mixing up measurements with the same timestamp.
Adding of new attribute 'iso_time: 2022-09-12T09:55:40.378983Z' is not hard, and it will not require additional memory because every measurement is relayed immediately to MQTT and we don't need to store this precise timestamp for all measurements.