Timestamps have wrong type

The timestamps have incorrect typescript types.
For example
https://github.com/kubernetes-client/javascript/blob/master/src/gen/model/v1ObjectMeta.ts#L32

creationTimestamp is of type Date | undefined, but the documentation says it's an RFC3339 formatted date aka a string.

Since this is generated code I'm not sure of where to fix this. Either the type has to change to string | undefined, or the string has to be parsed and passed on as a date object.

I don't think this is a bug. creationTimestamp is a v1.Time which is marked with openapi format: date-time in the spec here:
https://github.com/kubernetes/kubernetes/tree/master/api/openapi-spec

The swagger spec says: "Tools can use the format to validate the input or to map the value to a specific type in the chosen programming language." (https://swagger.io/docs/specification/data-models/data-types/)

So I think that this is a legit code generation given the openapi spec.

Is this causing problems for you?

let pod: V1Pod;
console.log(pod.metadata?.creationTimestamp, typeof pod.metadata?.creationTimestamp);

outputs 2020-07-23T06:01:17Z string

the type of V1Pod.metadata.creationTimestamp however is Date | undefined and not string | undefined

Possible solutions are converting the string to an actual Date object or change the typing to be a string.

@brendanburns

@brendanburns We are also experiencing problems because of this. The spec also defines the type as string even if the format is date-time

There is another scenario where the Date is broken: CoreV1Event.eventTime which is defined as a Date here, but the api server expects a metav1.MicroTime https://github.com/kubernetes/api/blob/master/events/v1beta1/types.go#L41

This what i have trying to post an event with eventTime set as a new Date() then converted into data.toISOString by models.js serialize method

message: 'Event in version "v1" cannot be handled as a Event: v1.Event.InvolvedObject: v1.ObjectReference.EventTime: unmarshalerDecoder: parsing time "2020-12-09T23:44:10.443Z" as "2006-01-02T15:04:05.000000Z07:00": cannot parse ".443Z" as ".000000", error found in #10 byte of ...|4:10.443Z","involved|..., bigger context ...|{"eventTime":"2020-12-09T23:44:10.443Z","involvedObject":{"kind":"Game","name":"monkey-is|...',

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

@brendanburns

@brendanburns could you please re-evaluate this?
/remove-lifecycle stale

Yep. The type declaration in typescript is wrong - it declares Date | undefined but the actual value (in runtime) is string | undefined...

It is difficult to work with, and caused a bug for us (we were expecting it to be Date, all tests pass, typescript checks pass, but in runtime it blows up, because it is string)

Either:

Change the typescript declaration to string | undefined
Or parse the date in the client and return actual Date object

@paolomainardi

What reported @paolomainardi seems to be related to kubernetes/kubernetes#89156: K8S could parse without problems Dates sent from the JavaScript client, but the format currently used to parse MicroTime is too strict.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

Would be nice if this gets fixed eventually...
/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

/lifecycle frozen

We'd like to contribute to fix this issue. Would a PR that changes the types of any Dates to be strings be accepted?

@Maistho

@Maistho unfortunately all of that code is generated. So you need to either change the openapi that Kubernetes generates, or you need to change the upstream openapi code generator (https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/resources/typescript)

If you successfully modify the upstream code generator, then we can regenerate with the new type.

@brendandburns

@brendandburns I think it should be possible to change this in the generator by adding the setting date-time=string,date=string in the typeMappings section in the typescript.xml file?

https://github.com/kubernetes-client/gen/blob/ea5af85f5bb75934bf7f3eb1edab1643e8caab47/openapi/typescript.xml#L39

As suggested in the issue on the openapi-generator repo: OpenAPITools/openapi-generator#926 (comment)

I think this should also affect the existing type mapping from date-time-micro to V1MicroTime (as that is most likely also a string), but I haven't verified that.

It seems like this might be (partially?) fixed in the newer typescript generator, but until that has been implemented using a typeMapping should resolve the issue.

@Maistho

@Maistho thanks for digging in.

If you want to try changing that and regenerating locally to validate that it works, we can see about getting it into the 0.19.0 release.

@brendandburns

Hey again @brendandburns, sorry for taking ages on this 😓

I did some testing tonight and changing the generator configuration like this results in dates being generated as strings instead, which is correct with how the data is actually sent from the API.

diff --git a/openapi/typescript.xml b/openapi/typescript.xml
index b33e5c9..8507e13 100644
--- a/openapi/typescript.xml
+++ b/openapi/typescript.xml
@@ -36,7 +36,7 @@
                                 <npmVersion>${generator.client.version}</npmVersion>
                                 <modelPropertyNaming>original</modelPropertyNaming>
                             </configOptions>
-                            <typeMappings>int-or-string=IntOrString,date-time-micro=V1MicroTime</typeMappings>
+                            <typeMappings>int-or-string=IntOrString,Date=string</typeMappings>
                         </configuration>
                     </execution>
                 </executions>

Removing date-time-micro=V1MicroTime is also needed since that's also sent as strings, and aren't deserialised into custom V1MicroTime objects. I'm not sure how that would factor into serialization.

Would you like me to open a pull request against the generator config repository with that change?

(I tested this on both the release-1.x branch and the master branch, both seems to yield correct results)

This seems to still be an issue. Are there any plans to fix this or workarounds?

Navigation Menu

Repository navigation

Timestamps have wrong type #487

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Timestamps have wrong type #487

Description

Activity

brendandburns commented on Aug 17, 2020

simhnna commented on Aug 19, 2020

Agreon commented on Oct 13, 2020

paolomainardi commented on Dec 9, 2020

fejta-bot commented on Mar 10, 2021

simhnna commented on Mar 18, 2021

DocX commented on Mar 29, 2021

michelle-laurenti commented on May 22, 2021

k8s-triage-robot commented on Aug 20, 2021

simhnna commented on Aug 30, 2021

k8s-triage-robot commented on Nov 28, 2021

8 remaining items

Maistho commented on Jun 26, 2022

k8s-triage-robot commented on Sep 24, 2022

Maistho commented on Sep 24, 2022

brendandburns commented on Dec 16, 2022

Maistho commented on Dec 26, 2022

brendandburns commented on Dec 30, 2022

Maistho commented on Dec 30, 2022

brendandburns commented on Dec 30, 2022

Maistho commented on Jun 2, 2023

bilalshaikh42 commented on Mar 30, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions