Valid ISO8601 date for observedAt is rejected with 400-Bad request

[wistefan]

Orion rejects objects with time-properties with fraction >=5.
Reproduce(fraction is .123456789):

curl --location --request POST 'http://localhost:1026/ngsi-ld/v1/entities' \
--header 'Content-Type: application/json' \
--data-raw '{ "id" : "urn:ngsi-ld:myentity:1",
  "type": "MyEntity",
  "location" : {
    "type" : "GeoProperty",
    "value" : {
      "type" : "Point",
      "coordinates" : [ 52.78, 13.27 ]
    },
    "observedAt" : "2022-02-01T03:20:00.123456789Z"
  }
}'

Response:

{
    "type": "https://uri.etsi.org/ngsi-ld/errors/BadRequestData",
    "title": "The 'observedAt' attribute must have a valid ISO8601 as value",
    "detail": "observedAt"
}

When the request is(fraction is .12345678):

curl --location --request POST 'http://localhost:1026/ngsi-ld/v1/entities' \
--header 'Content-Type: application/json' \
--data-raw '{ "id" : "urn:ngsi-ld:myentity:1",
  "type": "MyEntity",
  "location" : {
    "type" : "GeoProperty",
    "value" : {
      "type" : "Point",
      "coordinates" : [ 52.78, 13.27 ]
    },
    "observedAt" : "2022-02-01T03:20:00.12345678Z"
  }
}'

It succeeds.

[kzangeli]

Hopefully fixed in #1012

[jason-fox]

The POST request succeeds, but the ISO date is truncated.

curl --location --request GET 'http://localhost:1026/ngsi-ld/v1/entities/urn:ngsi-ld:myentity:1'

{
  "id": "urn:ngsi-ld:myentity:1",
  "type": "MyEntity",
  "location": {
    "type": "GeoProperty",
    "value": {
      "type": "Point",
      "coordinates": [
        52.78,
        13.27
      ]
    },
    "observedAt": "2022-02-01T03:20:00.123Z"
  }
}

Tested with latest:

{
    "orionld version": "post-v1.0.0",
    "orion version": "1.15.0-next",
    "uptime": "0 d, 0 h, 6 m, 43 s",
    "git_hash": "nogitversion",
    "compile_time": "Thu Feb 24 03:09:29 UTC 2022",
    "compiled_by": "root",
    "compiled_in": "",
    "release_date": "Thu Feb 24 03:09:29 UTC 2022",
    "doc": "https://fiware-orion.readthedocs.org/en/master/"
}

[kzangeli]

Yeah, only milliseconds are supported.
Sorry, but that's what we have right now.
It's not like the broker is really able to give any more precision in its timestamps ...
observedAt is user supplied, so, could make sense. createdAt/modifiedAt though are created by the broker and as it's not a real-time system, we can't really give any more precision than that. "observedAt" is treated the same, being of the same "type of property".

The issue is solved.
If another issue should be created - about "more than millisecond precision for observedAt", well, then let's open an issue about that.