in POST v2/entities, wrong values are allowed using DateTime type

[iariasleon]

in POST v2/entities, wrong values are allowed using DateTime type.

Dataset

      | attributes_value             |
      |------------------------------|
      | 2016-64-05T14:00:00.00Z      |
      | 20166405T140000Z             |
      | 2016-04-55T14:00:00.00Z      |
      | 2016-04-05T54:00:00.00Z      |
      | 2016-04-05T14:84:00.00Z      |
      | 2016-04-05T14:10-00.00Z      |
      | 2016-04-05T14:10:0x.00Z      |
      | 2016-04-05T14:10:.00Z        |
      | 26-04-05T14:00:00.00Z        |
      | 2016-04-05T14:00:00.00+45:00 |
      | 2016-04-05T14:00:00.00+15;00 |
      | 2016-04-05T14:00:00.00+1r:00 |
      | 2016-04-05T14:00:00.00+12:89 |
      | 2016-04-05T14:00:00.00+12:y7 |
      | 2016-04-05T14:00:00.00+1:00Z |

entity create request:

url: POST http://localhost1026/v2/entities
headers:
    Content-Type: application/json
    Fiware-Service: test_attributes_value
    Fiware-ServicePath: /test
payload: {"timestamp": {"type": "DateTime", "value": "2016-04-05T14:10:.00Z"}, "type": "house", "id": "room"}

response:

http code: 201 - Created
headers:
   Connection: Keep-Alive
   Content-Length: 0
   Location: /v2/entities/room?type=house
   Fiware-Correlator: 70ddc078-b2fb-11e6-916d-005056a20feb
   Date: Fri, 25 Nov 2016 10:39:28 GMT
payload:

expected response:

http code: 400 - Bad Request
payload: {"error":"BadRequest","description":"date has invalid format"}

[kzangeli]

I looked into this error and found the following:

parse8601Time(), instead of parsing the string, it relies on sscanf to do its work.
However, sscanf seems a little too forgiving. Traces illustrate the problem:

parse8601Time  msg=In parse8601Time
parse8601Time  msg=ss == '2016-04-05T14:10:.00Z'
parse8601Time  msg=y  == '2016'
parse8601Time  msg=M  == '4'
parse8601Time  msg=d  == '5'
parse8601Time  msg=h  == '14'
parse8601Time  msg=m  == '10'
parse8601Time  msg=s  == '0.000000'
parse8601Time  msg=tz == 'Z'
parseContextAttributeObject  msg=parse8601Time returned 139789388937680

Look at the string for seconds: .00. This is a valid float and sscanf does just what it is told.
However, inside an ISO8601, the initial zero (actually two zeroes) in 00.00 cannot be left out.

This string ('2016-04-05T14:10:.00Z') should give a parse error for ISO8601 but it passes through as a valid date.

The calls to scanf use %d for all components except tz that is a char vector and seconds that is a float.
Perhaps changing seconds to a char vector and then examining that char vector could solve the problem.

Not sure about the format of 'seconds as char vector' for sscanf though ... Perhaps seconds and timezone must be combined into a char vector ...

[fgalan]

Related with #2303

[fgalan]

(Feedback required from @fgalan)