dateEncodingFormatter inconsitent format?HI,

[b00tsy]

Excellent framework which makes my live a lot easier! Although the learning curve could be less steep as I believe that the auto-generated documentation is out of date.

I have problems with dateEncodingFormatter of Coding. Is there a reason why the used format differs from the ones defined in dateDecodingFormatters?

yyyy-MM-dd'T'HH:mm:ss.Z the dot just before Z seems wrong to me and it makes my swagger validator on the backend reject the submitted date, eg. 2019-01-01T12:12:12.Z. On top of that I need fractional accuracy as in one of the formats in the decoding formatter. Is it possible to customize the encoding formatter somehow without manually adjusting Coding.swift every time after an export?

[yonaskolb]

Hi @b00tsy, glad you’re getting some use of of it! Those date formatters are public properties so they can be modified. You can just set DateTime.dateEncodingFormatter.formatString = “...”.
The reason why decoding uses an array of formatters is so it can decode a few different types, as backend formats can vary slightly. On encoding though we have to have a single explicit format

[b00tsy]

Thanks that hint solves my requirement of using fractional seconds! But is the default value `yyyy-MM-dd'T'HH:mm:ss.Z` a correct ISO8601 format (I’m wondering about the dot just before the Z)? My node.js swagger validator `swagger-express-middleware` () rejects date-times coming in that format. If I change it to eg. `yyyy-MM-dd'T'HH:mm:ssZ` (without the dot before the Z) or any of the formats you defined in dateDecodingFormatters the validator is happy.

…

On 3. Feb 2019, at 01:20, Yonas Kolb ***@***.***> wrote: Hi @b00tsy <https://github.com/b00tsy>, glad you’re getting some use of of it! Those date formatters are public properties so they can be modified. You can just set DateTime.dateEncodingFormatter.formatString = “...”. The reason why decoding uses an array of formatters is so it can decode a few different types, as backend formats can vary slightly. On encoding though we have to have a single explicit format — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#116 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQsSBnfEvYFXakpnqTFM1dxHPuZEv_kks5vJitOgaJpZM4afykp>.

[yonaskolb]

Yeah I'm not sure actually. I think a backend on a project a few years ago must of passed strings back in that format, so it's been there ever since

[yonaskolb]

I'll close this for now. Let me know if you have any more questions or issues