Timestamps have wrong type

[simhnna]

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.

[brendandburns]

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?

[simhnna]

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.

[Agreon]

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

[paolomainardi]

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|...',

[fejta-bot]

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

[simhnna]

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

[DocX]

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

[asmeikal]

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.

[k8s-triage-robot]

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

[simhnna]

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

[k8s-triage-robot]

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