"timestamp" field in OCPP 2.0.1 messages do not comply with the specified formatting

[Wolfy7]

Description

The OCPP 2.0.1 specification defines the format for dateTime datatypes as folowed:

If you create a StatusNotificationRequest with chrono::Utc::now()

StatusNotificationRequest {
            timestamp: chrono::Utc::now(),
            evse_id: 1,
            connector_id: 1,
            connector_status: ConnectorStatusEnumType::Available,
        }

the json output will look like:

{\"Call\":[2,\"mL0tHk5z9CwvfCpX1HKTKYxEGyeUlYxaEejR\",\"StatusNotification\",{\"timestamp\":\"2025-02-25T20:53:10.093684808Z\",\"connectorStatus\":\"Available\",\"evseId\":1,\"connectorId\":1}]}

chrono stores the DateTime<Utc> with high precision (nanoseconds) so:

chrono::Utc::now() would result in 2025-02-25 20:53:10.093676623 UTC

Solution

Probably a solution could be to use #[serde(with = "ts_milliseconds")] for timestamp field in OCPP 2.0.1 messages.

[tommymalmqvist]

@Wolfy7 thank you nice find. Looks like round_subsecs(3) also works

example

use chrono::{SubsecRound, Utc};

fn main() {
    let now = Utc::now();
    let rounded = now.round_subsecs(3); // Rounds to 3 decimal places

    // to json
    let json = serde_json::to_string(&rounded).unwrap();
    println!("JSON: {}", json);
}

Gives

JSON: "2025-02-26T12:43:56.379Z"

[tommymalmqvist]

Actually we can use the RFC referenced like this

use chrono::Utc;

fn main() {
    let now = Utc::now();

    let json =
        serde_json::to_string(&now.to_rfc3339_opts(chrono::SecondsFormat::Millis, true)).unwrap();
    println!("JSON: {}", json);
}

which produces

JSON: "2025-02-26T12:55:01.741Z"

[Wolfy7]

@tommymalmqvist

Yes, looks like this would work also.

And is probably much "nicer" then what I came up with :)

        let now = Utc::now();
        let formatted = now.to_rfc3339_opts(SecondsFormat::Millis, true); // max. 3 decimal places, “Z” as UTC
        DateTime::parse_from_rfc3339(&formatted)
            .expect("Invalid date")
            .with_timezone(&Utc)

I just thought that there would maybe a way where this could be done "automatcly", with serde option or so.

But maybe only possible with own "serialize/deserialize" implementation.

[Wolfy7]

Actually we can use the RFC referenced like this

use chrono::Utc;

fn main() {
let now = Utc::now();

let json =
    serde_json::to_string(&now.to_rfc3339_opts(chrono::SecondsFormat::Millis, true)).unwrap();
println!("JSON: {}", json);

}
which produces

JSON: "2025-02-26T12:55:01.741Z"

This will not work together with for example StatusNotificationRequest because to_rfc3339_opts returns an String but the timestamp in StatusNotificationRequest has to be DateTime<Utc>,

[tommymalmqvist]

Actually we can use the RFC referenced like this
use chrono::Utc;
fn main() {
let now = Utc::now();

let json =
    serde_json::to_string(&now.to_rfc3339_opts(chrono::SecondsFormat::Millis, true)).unwrap();
println!("JSON: {}", json);

}
which produces
JSON: "2025-02-26T12:55:01.741Z"

This will not work together with for example StatusNotificationRequest because to_rfc3339_opts returns an String but the timestamp in StatusNotificationRequest has to be DateTime<Utc>,

@Wolfy7 Ok from the docs you mentioned it seems we get unix epoch time?

[Wolfy7]

Actually we can use the RFC referenced like this
use chrono::Utc;
fn main() {
let now = Utc::now();

let json =
    serde_json::to_string(&now.to_rfc3339_opts(chrono::SecondsFormat::Millis, true)).unwrap();
println!("JSON: {}", json);

}
which produces
JSON: "2025-02-26T12:55:01.741Z"

This will not work together with for example StatusNotificationRequest because to_rfc3339_opts returns an String but the timestamp in StatusNotificationRequest has to be DateTime<Utc>,

@Wolfy7 Ok from the docs you mentioned it seems we get unix epoch time?

Yes, looks like that this will also not really work.

[tommymalmqvist]

@Wolfy7 A custom serde serializer that uses datetime.to_rfc3339_opts(SecondsFormat::Millis, true).to_string(); might be the best approach

[Wolfy7]

@Wolfy7 A custom serde serializer that uses datetime.to_rfc3339_opts(SecondsFormat::Millis, true).to_string(); might be the best approach

Yes, thats also my opinion.

Something like:

use chrono::DateTime;
use chrono::SecondsFormat;
use chrono::Utc;
use serde::{Deserialize, Deserializer, Serializer};

use crate::v2_0_1::enumerations::connector_status_enum_type::ConnectorStatusEnumType;

/// Sent by the Charging Station to the CSMS to request that the Certificate Authority signs the public key into a certificate.
#[derive(serde::Serialize, serde::Deserialize, Debug, Clone, PartialEq, Default)]
#[serde(rename_all = "camelCase")]
pub struct StatusNotificationRequest {
    #[serde(serialize_with = "serialize", deserialize_with = "deserialize")]
    pub timestamp: DateTime<Utc>,
    pub connector_status: ConnectorStatusEnumType,
    pub evse_id: i32,
    pub connector_id: i32,
}

/// This contains the field definition of StatusNotificationResponse sent by the CSMS to the Charging Station in response to a StatusNotificationRequest. This message is deprecated. This message might be removed in a future version of OCPP. It will be replaced by Device Management Monitoring events.
#[derive(serde::Serialize, serde::Deserialize, Debug, Clone, PartialEq, Default)]
#[serde(rename_all = "camelCase")]
pub struct StatusNotificationResponse {}

fn serialize<S>(date: &DateTime<Utc>, serializer: S) -> Result<S::Ok, S::Error>
where
    S: Serializer,
{
    serializer.serialize_str(&date.to_rfc3339_opts(SecondsFormat::Millis, true))
}

fn deserialize<'de, D>(deserializer: D) -> Result<DateTime<Utc>, D::Error>
where
    D: Deserializer<'de>,
{
    let s: String = Deserialize::deserialize(deserializer)?;
    DateTime::parse_from_rfc3339(&s)
        .map(|dt| dt.with_timezone(&Utc))
        .map_err(serde::de::Error::custom)
}

would work and give String("2025-02-26T13:39:48.853Z")

But would also need to set the feature alloc in Cargo.toml

chrono = { version = "0.4.39", default-features = false, features = ["serde", "alloc"] }

[Wolfy7]

@tommymalmqvist

I created a PR #153 which should work. Please have a look