Invoice field `date` and `dueDate` not matching typescript definition

[gjuchault]

SDK you're using (please complete the following information):

• Version: 4.9.1

Describe the bug

The Invoice model in TypeScript is not matching the actual invoice entities returned by the SDK.

In the typescript definition:

    /**
    * Date invoice was issued – YYYY-MM-DD. If the Date element is not specified it will default to the current date based on the timezone setting of the organisation
    */
    'date'?: string;
    /**
    * Date invoice is due – YYYY-MM-DD
    */
    'dueDate'?: string;

If you look to the result of createInvoices (Date instance):

To Reproduce
Steps to reproduce the behavior:

1. Do a getInvoice or createInvoices call

Expected behavior

• date field to be a string

[jamesrusso]

I am seeing the same issue on BankTransaction. Any updates or workarounds?

[mbyrne00]

Oh man ... this is so bad. I just got caught with this today. We had luckily been handling this because we were previously using moment to convert it and by fluke the "all purpose" constructor of moment just handled it. Finally switched to luxon and saw this.

The typing is wrong, the date format of the API is wrong (it's the old .NET format in the underlying api but the JSDoc says YYYY-MM-DD). This really needs update and not sure why it's been left so long without answering it. I've had to write a generic util to parse xero dates as string | Date since I have no confidence in what the library is doing.

I can definitely see in the deserialize function that it's creating a Date

    static deserialize(data, type) {
        // polymorphism may change the actual type.
        type = ObjectSerializer.findCorrectType(data, type);
        if (data == undefined) {
            return data;
        }
        else if (primitives.indexOf(type.toLowerCase()) !== -1) {
            if (type === "string" && data.toString().substring(0, 6) === "/Date(") {
                return this.deserializeDateFormats(type, data); // For MS dates that are of type 'string'
            }
            else {
                return data;
            }
        }
  ....

Even though the type map specifies it as string, the function sees it starts with /Date( and converts it to a Date

@SerKnight - are you able to assist with this one? I think it's fine that they are converted to Date ... I think the expected behaviour is not to change it to string but to update the typings to be correct. Seems like all date fields are affected in all responses.

[winterec]

This is still not resolved in the latest 9.3.0-alpha.5

A workaround for my case of needing the original date as a string:
(payment.date as unknown as Date).toISOString().substring(0, 10)

[rowandh]

#746 is a duplicate of this.

[limcw1212-arch]

#487