FIX documentation and changelog

CHANGES_NEXT_RELEASE

@@ -1,4 +1,4 @@
-- Fix timestamp attribute mapped cases (#1557)
+- Fix: TimeInstant mapped from measure overrides system TimeInstant (#1557)
 - Fix: reduce information showed handling errors to just config flags (#1594)
 - Upgrade express dep from 4.18.1 to 4.19.2
 - Add: allow devices with the same device_id in the same service and subservice but different apikey (#1589)

doc/api.md

@@ -972,13 +972,11 @@ Will now generate the following NGSI v2 payload:
 
 ## Timestamp Processing
 
-The IOTA processes the entity attributes looking for a `TimeInstant` attribute. If one is found, for NGSI v2, then it
-adds a `TimeInstant` attribute as metadata for every other attribute in the same request. With NGSI-LD, the Standard
-`observedAt` property-of-a-property is used instead.
+Timestamp processing done by IOTA is as follows:
 
-If a `TimeInstant` arrives as measure but not follows [ISO_8601](https://en.wikipedia.org/wiki/ISO_8601) then measure is
-refused. In this case `TimeInstant` could be mapped to an attribute and then modified by an expression, see the
-[Expression Language definition](#expression-language-support) for details
+* An attribute `TimeInstant` is added to updated entities
+* In the case of NGSI-v2, a `TimeInstant` metadata is added in each updated attribute. With NGSI-LD, the Standard
+`observedAt` property-of-a-property is used instead.
 
 Depending on the `timestamp` configuration and if the measure contains a value named `TimeInstant` with a correct value,
 the IoTA behaviour is described in the following table:
@@ -992,16 +990,19 @@ the IoTA behaviour is described in the following table:
 | Not defined            | Yes                            | TimeInstant and metadata updated with measure value    |
 | Not defined            | No                             | TimeInstant and metadata updated with server timestamp |
 
-If there is an attribute with maps a measure to a TimeInstant, then that value will be used as a default TimeInstant,
-overwriting the above rules, that is, a `TimeInstant` measure or server timestamp.
-
-The `timestamp` value used is:
+The `timestamp` conf value used is:
 
 -   The one defined at device level
 -   The one defined at group level (if not defined at device level)
 -   The one defined at [IoTA configuration level](admin.md#timestamp) / `IOTA_TIMESTAMP` env var (if not defined at
     group level or device level)
 
+Some additional considerations to take into account:
+
+* If there is an attribute which maps a measure to `TimeInstant` attribute (after [expression evaluation](#expression-language-support) if any is defined), then that value will be used as as `TimeInstant,
+overwriting the above rules specified in "Behaviour" column. Note that an expression in the  could be used in that mapping.
+* If the resulting `TimeInstant` not follows [ISO_8601](https://en.wikipedia.org/wiki/ISO_8601) (either from a direct measure of after a mapping, as described in the previous bullet) then it is refused (so a failover to server timestamp will take place).
+
 ## Overriding global Context Broker host
 
 **cbHost**: Context Broker host URL. This option can be used to override the global CB configuration for specific types