OCPP date-time types should have only seconds precision

[Dominik-K]

The DateTime class in ocpp/common/ uses internally the std::chrono::time_point<date::utc_clock> which has a sub-second precision by default (at least on most platforms). When this time_point is initialized with a value with lower precision, e.g. from a CSMS message or the database, then the sub-second fractions have arbitrary values. But the ==-equality-check is simply done on the time_points:

libocpp/lib/ocpp/common/types.cpp

Lines 95 to 97 in 6f73dec

	bool operator==(const DateTimeImpl& lhs, const DateTimeImpl& rhs) {
	return lhs.timepoint == rhs.timepoint;
	}

That leads to a failure in the database-tests (thanks @couryrr-afs for catching it). It can be easy verified by using the .to_time_point() in the GTest assertions.

Solution

The DateTime's internal timepoint should only have seconds precision. As in both OCPP-versions, the sub-second precision may be omitted:

OCPP 1.6 spec (edition 2 FINAL, 2017-09-2), 3.15. Time notations:

Implementations MUST use ISO 8601 date time notation. Message receivers must be able to handle fractional
seconds and time zone offsets (another implementation might use them). Message senders MAY save data
usage by omitting insignificant fractions of seconds. [emphasis mine]

OCPP 2.0.1 spec (Edition 2 FINAL, 2022-12-15), 3.1. Time Format Requirements:

All time values exchanged between CSMS and Charging Station SHALL be formatted as defined in RFC-3339 [RFC3339].
Additionally fractional seconds have been given an extra limit. The number of decimal places SHALL NOT exceed the maximum of 3. However, it is RECOMMENDED to omit fractional seconds entirely, because it is of limited use and omitting it reduces data usages. [emphasis mine]

But the DateTime-class is also used for other internal types (which are not OCPP-messages). At least changing the precision fails a message_queue unit-test which hints that perhaps the internal-types need sub-second precision. See #383

Given that, I suggest to add a new type DateTimeSeconds(Precision) and deliberately use this in the OCPP-message related types. Then the remaining usages could be checked on precision-level later. (This approach resembles the Open-closed principle, I guess.)

[Dominik-K]

@RobertDeLeeuw RFC on the OCPP handling

[RobertDeLeeuw]

Bit of background. Mean reason to ommit milliseconds in OCPP. OCPP is not real time. Sending over milliseconds in every message would only increase the amount of data over the line without adding anything useful for users.

[RobertDeLeeuw]

I think the best solution would be to have functionality to send and receive OCPP without milliseconds and when comparing OCPP "timestamps" to compare without milliseconds. So you could also opt for OCPP specific timestamp compare functions. That dont take milliseconds into account. Adding a new data type would result in the same kind of functions.

On the otherhand. Adding a new datatype that supports comparing against its own type and DateTime-class would code wish maybe provides the cleanest code.

[ahzf]

That is just YOUR interpretation of "OCPP Legacy" ;)

Fractions of seconds are often important when the order of events is important and TIME should be strictly growing monotonically. But it is a good question where we need this in "normal" OCPP. In most cases you can ignore it, but whenever we come to e.g. grid management operations you have to deal with msecs.

So the OCPP text is quite good: Ignore the fractions, unless you have a good reason not to ignore them.