kaikreuzer
commented
5 years ago Afair, this has been discussed a few times already and many years ago - I don't have a suitable reference to it, though.
The tricky question is, what this timestamp is supposed to express exactly. You say it is "the the time of the event creation". When is this exactly? The moment that e.g. the measurement is taken by the (external) sensor? The moment that the binding code creates the event? The moment that the framework publishes the event? What do you do, if you receive an event for an item with an older timestamp than another one you received before? Do you dismiss it? What does it mean for your time series in the database if timestamps aren't in chronological order?
Due to all those questions and arising issues, we have so far decided to not add timestamps to events, but rather have the HistoricItem interface, which is a DTO with an item state and a timestamp. This DTO is used by the persistence layer and it is guaranteed that the timestamps of all data that is persisted is in chronological order - your persistence use case is imho therefore covered.
Wrt having a unique identifier: This is imho a different kind of requirement and a timestamp might not be the best solution to it.
I would like to discuss the option to add a timestamp field ("ts" or perhaps because of metainfo "_ts") to the Eclipse SmartHome events (Event interface and on every payload bean). IMHO it should not harm if not needed but it could be used on consuming events to get the time of the event creation perhaps to persistent changed events on a local database, in a cloud storage, ... It can also be used as an unique identifier for an event and to find identical events that are received by different event subscribers.