NGSI-LD observedAt is ignoring timezone from service or device for multivariable sensor

[konstantinosGombakis]

I provision a service with "timezone": "Asia/Tokyo" using MQTT binding.
The sensor push several attributes/measruements. The issue is the timezone for observedAt is always UTC and ignoring any timezone provided by service or device.

Docker image date time: Thu Dec 14 11:53:07 UTC 2023
IoT Agent log -> "observedAt": "2023-12-14T11:53:07.152Z**"
Orion-LD -> "observedAt": "2023-12-14T11:53:07.152Z"
What i expected Orion-LD -> "observedAt": "2023-12-14T20:53:07.152Z"

Maybe the bug is here

[fgalan]

Maybe @jason-fox could provide some feedback on this

[jason-fox]

In NGSI-LD, all dates are defined using ISO 8601: 2004 Data elements and interchange formats -- Information interchange --Representation of dates and times.

Specifically. from the ETSI NGSI-LD Specification

4.6.3 Supported data types for Values

Compliant NGSI-LD implementations shall support the following data types for representing Values:

• DateTime string for encoding a timestamp, i.e. a calendar date together with a time of day, expressed in UTC,
  using the ISO 8601 [17] Complete Representation and in particular using the 'Extended Format', as described
  below:
• The timestamp shall be a string containing Year, Month, Day, Hours, Minutes, Seconds and time zone
  components using the format YYYY-MM-DDThh:mm:ssZ as defined in ISO 8601 [17]. In this
  representation, the character "-" is used to separate the calendar date components, the character "T" is
  used to indicate the start of the time of day portion, the character ":" is used to separate the time of day
  components, and the trailing character "Z" is used to convey the time zone.
• All the referred components shall appear in the string; reduced representations are not permitted.
• The Seconds component may optionally contain a decimal fraction. In this case the string shall contain
  two integer digits, followed by a decimal point and then one or more fractional digits, up to a maximum
  of six. For example, YYYY-MM-DDThh:mm:ss.ssssssZ.
• The trailing timestamp component shall contain the time zone related information and shall always be
  equal to the character "Z". Therefore, all timestamps shall be expressed in UTC.

I guess the reason behind this is because NGSI-LD is primarily used for data exchange and data spaces. Date formats are tricky things and if only Zulu time is supported for everything then it makes exchange easier. For example if you are retrieving data from a federation of multiple brokers, then the value with with most recent observedAt "wins" - only supporting Zulu time avoids any offsets for this comparison.

[konstantinosGombakis]

@jason-fox Thanks a lot for the explanation. I missed these ETSI NGSI-LD Specs. Can you please add it on some of your very useful tutorials. So i supposed that i need to add to the sensor entity on the Context Broker the timezone as a static_attributes so i the end to have the correct time of the measurement.