Date Format ASR9K 6.1.4 - openconfig-interfaces.interface.state.counters.last-clear

[rbergma]

I'm getting the following obnoxious error.  I'm assuming this is coming from YDK.  the date is coming from last-clear in counters

Value "2017-08-21 23:24:38.587 UTC" does not satisfy the constraint "\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[\+\-]\d{2}:\d{2})" (range, length, or pattern). Path: /openconfig-interfaces:interfaces/interface[name='TenGigE0/0/0/0']/state/counters/last-clear

perhaps there is a way to format the date in the equipment to comply with the expected results?

class Counters(Entity):
	"""
	A collection of interface\-related statistics objects.
	.. attribute:: in_octets
	[adapted from IETF interfaces model (RFC 7223)] The total number of octets received on the interface, including framing characters. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: in_unicast_pkts
	[adapted from IETF interfaces model (RFC 7223)] The number of packets, delivered by this sub\-layer to a higher (sub\-)layer, that were not addressed to a multicast or broadcast address at this sub\-layer. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: in_broadcast_pkts
	[adapted from IETF interfaces model (RFC 7223)] The number of packets, delivered by this sub\-layer to a higher (sub\-)layer, that were addressed to a broadcast address at this sub\-layer. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: in_multicast_pkts
	[adapted from IETF interfaces model (RFC 7223)] The number of packets, delivered by this sub\-layer to a higher (sub\-)layer, that were addressed to a multicast address at this sub\-layer. For a MAC\-layer protocol, this includes both Group and Functional addresses. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: in_discards
	[adapted from IETF interfaces model (RFC 7223)] Changed the counter type to counter64. The number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher\-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: in_errors
	[adapted from IETF interfaces model (RFC 7223)] Changed the counter type to counter64. For packet\-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher\-layer protocol. For character\- oriented or fixed\-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher\-layer protocol. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: in_unknown_protos
	[adapted from IETF interfaces model (RFC 7223)] Changed the counter type to counter64. For packet\-oriented interfaces, the number of packets received via the interface that were discarded because of an unknown or unsupported protocol. For character\-oriented or fixed\-length interfaces that support protocol multiplexing, the number of transmission units received via the interface that were discarded because of an unknown or unsupported protocol. For any interface that does not support protocol multiplexing, this counter is not present. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..4294967295
	.. attribute:: out_octets
	[adapted from IETF interfaces model (RFC 7223)] Changed the counter type to counter64. The total number of octets transmitted out of the interface, including framing characters. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: out_unicast_pkts
	[adapted from IETF interfaces model (RFC 7223)] The total number of packets that higher\-level protocols requested be transmitted, and that were not addressed to a multicast or broadcast address at this sub\-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: out_broadcast_pkts
	[adapted from IETF interfaces model (RFC 7223)] The total number of packets that higher\-level protocols requested be transmitted, and that were addressed to a broadcast address at this sub\-layer, including those that were discarded or not sent. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: out_multicast_pkts
	[adapted from IETF interfaces model (RFC 7223)] Changed the counter type to counter64. The total number of packets that higher\-level protocols requested be transmitted, and that were addressed to a multicast address at this sub\-layer, including those that were discarded or not sent. For a MAC\-layer protocol, this includes both Group and Functional addresses. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: out_discards
	[adapted from IETF interfaces model (RFC 7223)] Changed the counter type to counter64. The number of outbound packets that were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: out_errors
	[adapted from IETF interfaces model (RFC 7223)] Changed the counter type to counter64. For packet\-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character\-oriented or fixed\-length interfaces, the number of outbound transmission units that could not be transmitted because of errors. Discontinuities in the value of this counter can occur at re\-initialization of the management system, and at other times as indicated by the value of 'discontinuity\-time'
	**type**\: int
	**range:** 0..18446744073709551615
	.. attribute:: last_clear
	Indicates the last time the interface counters were cleared
	**type**\: str
	**pattern:** \\d{4}\-\\d{2}\-\\d{2}T\\d{2}\:\\d{2}\:\\d{2}(\\.\\d+)?(Z\|[\\+\\\-]\\d{2}\:\\d{2})

[abhirame · Accepted solution]

In the newer version of software (newer than 6.1.4), the data is returned correctly:

2018-02-06T16:05:45.783+00:00

So it appears the issue has been fixed. To work around this issue with your current device, can you please add a check for this in your code. Perhaps by catching this exception?

[rbergma]

The library returns the error and no data.  No point in catching the error since there is no data returned.  Only option is to upgrade the device.  To be fair, the ietf standard that is used as the source for the openconfig standard doesn't have a spec for last_clear from my light standards browsing.  Sadly, i chose the wrong version to upgrade to thinking mature would be better.  The funny part is, i chose 6.1.4 because the previously installed version didn't support the netconf/yang interface.  Thanks for the info.