Timestamp deserialization fails on well-formatted timestamps depending on number of nanosecond digits

[anekdoti]

Describe the bug
Timestamp deserialization is more limited than Kubernetes API conventions allow. I.e., there are timestamps that are fine according to Kubernetes API conventions (e.g., lastTransitionTimestamp in status conditions) that can not be deserialized using the C# Kubernetes client but instead raise an exception like shown below.

More precisely, the C# Kubernetes client only allows either exactly 6 digits for nanoseconds or none at all, whereas an arbitrary number < 10 is actually possible.

Kubernetes C# SDK Client Version
Observed on 10.0.31, but according to the implementation of KubernetesDateTimeOffsetConverter on the master branch we expect the bug to occur on master as well.

Server Kubernetes Version
1.24.14

Dotnet Runtime Version
net6

To Reproduce
Create a Kubernetes resource with a status condition where the lastTransitionTimestamp has e.g. 9 nanosecond positions.
Attempt to read the resource with the generic client of the C# Kubernetes Client. The exception shown below will be thrown.

Expected behavior
The Kubernetes resource should be read properly, including the lastTransitionTimestamp of the status condition.

Where do you run your app with Kubernetes SDK (please complete the following information):
The Kubernetes SDK is used in a container running the image mcr.microsoft.com/dotnet/sdk:6.0-alpine3.16 in Kubernetes 1.24.14.

Additional context
According to the Kubernetes API conventions, the lastTransitionTimestamp should be deserializable as a Golang Time struct. The deserialization of a string into such a struct follows the conventions of RFC3339 and its implementation in particular allows an arbitrary number of nanosecond digits from 0 to 9.

We actually faced this problem in practice trying to read a KafkaConnector resource by the Strimzi operator that contained a status condition with the lastTransitionTimestamp as shown in the exception below. According to the Kubernetes API conventions, this timestamp is well-formatted and should be deserialized correctly.

The KubernetesDateTimeOffsetConverter in the C# Kubernetes Client however only allows either 0 or 6 nanosecond digits.

Exception

System.FormatException: String '2023-07-26T11:17:34.255606088Z' was not recognized as a valid DateTime.
   at System.DateTimeParse.ParseExactMultiple(ReadOnlySpan`1 s, String[] formats, DateTimeFormatInfo dtfi, DateTimeStyles style, TimeSpan& offset)
   at System.DateTimeOffset.ParseExact(String input, String[] formats, IFormatProvider formatProvider, DateTimeStyles styles)
   at k8s.KubernetesJson.KubernetesDateTimeConverter.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader)
   at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonCollectionConverter`2.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, TCollection& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader)
   at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader)
   at System.Text.Json.Serialization.Converters.ObjectWithParameterizedConstructorConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)
   at System.Text.Json.Serialization.JsonConverter`1.ReadCore(Utf8JsonReader& reader, JsonSerializerOptions options, ReadStack& state)
   at System.Text.Json.JsonSerializer.ReadFromSpan[TValue](ReadOnlySpan`1 utf8Json, JsonTypeInfo jsonTypeInfo, Nullable`1 actualByteCount)
   at System.Text.Json.JsonSerializer.ReadFromSpan[TValue](ReadOnlySpan`1 json, JsonTypeInfo jsonTypeInfo)
   at System.Text.Json.JsonSerializer.Deserialize[TValue](String json, JsonSerializerOptions options)
   at k8s.GenericClient.ReadNamespacedAsync[T](String ns, String name, CancellationToken cancel)

[tg123]

should support go type time.RFC3339Nano
let me check if there is any reason for 6 digits

link #609

[tg123]

are you talking about this

https://github.com/strimzi/strimzi-kafka-operator/blob/8ef93742b00cd42f86a62eb29170756c60f6819b/api/src/main/java/io/strimzi/api/kafka/model/status/Condition.java#L69

    @Description("Last time the condition of a type changed from one status to another. " +
            "The required format is 'yyyy-MM-ddTHH:mm:ssZ', in the UTC time zone")
    public String getLastTransitionTime() {
        return lastTransitionTime;
    }

[anekdoti]

Exactly. Indeed, the Strimzi cluster operator does seem to diverge from the format in the description of the method, and if it would respect it, the C# Kubernetes client would not have a problem with deserialization.

But I think the problem is not really on the side of Strimzi and the C# Kubernetes client should either way be able to handle different numbers of nanosecond digits apart from 6, e.g., 9 as used when a Golang Time struct is serialised with layout RFC3339Nano.

[tg123]

after some local test, c# support 7 digits at most :(

https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings#lowercase-seconds-f-fraction-specifier

[anekdoti]

It doesn't only seem to be limitation of parsing, but an intrinsic problem of the DateTime type: dotnet/runtime#30204.

Then the following question turns up: What would be worser? That certain Kubernetes resources can not be read by the C# Kubernetes Client (and I think the lastTransitionTimestamp in status conditions is not a special case, but it can happen for all kinds of timestamps), or that it is read but precision is reduced to multiples of 100 nanoseconds?

I would think the latter would be better, but it would need some custom string manipulation. I could imagine that it would be easy to split the string at the nanoseconds, parse up to seconds and then use AddTicks to set the nanoseconds from the rest of the string.

[tg123]

i am good to support rfc3339nano in sdk, but seems additional work required to parse it
lets trim it to 7 digits first

[anekdoti]

I think that would already help a lot. Thank you!

[anekdoti]

Hello @tg123, I am not sure how to proceed. Do you already have an idea for a fix or would you appreciate a PR from my side?

[tg123]

PR is welcomed
you can add regex trim based on my PR