Presumably the issue is that the device does not itself have a clock, or it could just put this information into the payload or a user property.

There are many messaging protocols where the server adds a timestamp to the message.. This is useful for many cases other than retained messages.

However, in order to get any reasonable amount of interoperability we would need to define a property for this, and also define the format, epoch, and resolution of the timestamp.

I see three possible dispositions for this:

1. Do nothing

2. Say that the server is allowed to add a user property to a forwarded message. We should need to talk about the server being allowed to modify such a property when forwarding.

3. Define a property on the PUBLISH which represents a timestamp, and say the the server is allowed to add or modify this property when the message is forwarded.

If we go with solution 3, we need to further define the type and semantics of the timestamp. I will throw out three suggestions for this:

1. Define an Eight byte integer as the type, and the value as milliseconds into the Unix epoch (1970-01-01T00Z ignoring leap seconds). This is the Java tiemstamp. Alternately, a resolution of microseconds or nanoseconds could be used.

2. Define the value as a string in ISO8601 format and require that it start with the year. The resolution could be arbitrary as the decimal places after the seconds. The time zone could be specified or default to UTC.

3. Two Four byte integers, the first representing seconds into the Unix epoch, and the second nanoseconts beyond that second. This is pure Unix time format.

One more option (call it 1a). If the receiver of the message knows the publication expiry with which the message was sent, the delta publication expiry tells the receiver how long it is since the retained message was sent. This is a mechanism widely used in TCP to determine the hop count by looking at the TTL. This has the advantage that there is no change to any existing spec or code. At most we could point this out in a non-normative comment.

This was discussed at the 2017-09-28 TC. The decision was to take no action.

It was noted that the receiving client can determine the publish time of a retained message with expiry if it knows the original expiry time. The sending application is free to put a timestamp into the payload or within a user property.

It was also agreed that while a server is required to forward all user properties with a message, it is not prohibited from adding its own.