date-and-time value "0000-00-00T00:00:00+00:00"

[macauley]

Greetings,

I have a device that has defined within their YANG an leaf element as follows:

leaf AlarmDeclDateAndTime{
    type yang:date-and-time;
    description "Alarm declaration date and time in the format YY-MM-DD-HH-MM-SS.";
}

During the initial "sync-from" process NCS is failing discovery with the following error:

invalid value for: AlarmDeclDateAndTime in /ncs:devices/ncs:device[ncs:name='Lab1']/ncs:config/config-timer-alarms:timer-alarms/config-timer-alarms:timer-alarm[config-timer-alarms:MoId='EQPPER1']/config-timer-alarms:AlarmDeclDateAndTime: "0000-00-00T00:00:00+00:00" is not a valid value.

I verified the value being returned through a NETCONF query:

<AlarmDeclDateAndTime>0000-00-00T00:00:00+00:00</AlarmDeclDateAndTime>

The timestamp "0000-00-00T00:00:00+00:00" appears to be a legal given the following YANG date-and-time definition:

    typedef date-and-time {
      type string {
        pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
               + '(Z|[\+\-]\d{2}:\d{2})';
      }
    }

However, it violates the definition in RFC 3339 for month and day range.  Is this the reason for the "is not a valid value" error?

The issue at hand is there are a couple of equipment vendors that are using this "0000-00-00T00:00:00+00:00" value when the time is unknown.  Given they have defined the element as optional, there is no reason to include it.  Just want to make sure this is really an invalid date before opening a ticket with them.

Thank you!

[vleijon · Accepted solution]

If you look at RFC6021 it references RFC3339, so yes, there is additional validation to ensure compliance with that. So, the devices are non-standards compliant. One thing you can do as a quick workaround is to go into the models for the NETCONF NED and change the type to string, or even to the pattern in the RFC, without using the type.