Don't generate format: date as Foundation.Date, use a string

[czechboy0]

This comment from @yanniks made me check what type we generate for format: date (not date-time), and it's Foundation.Date. That's wrong, as Foundation.Date only represents a full timestamp (aka date-time in OpenAPI terms).

This is an oversight, we should just generate a simple string, as there isn't an obvious currency type to deserialize dates (without time) into.

Should be as simple as removing .date from here.

[yanniks]

Hi Honza,

thanks for opening this issue! I agree that changing date values to a string is definitely a better solution than the current implementation, especially since the default ISO8601DateTranscoder is not able to decode OpenAPI date formats at all.

However, I would prefer some kind of predefined date object as the format (yyyy-MM-dd) is fixed. Otherwise, all developers will have to implement their own (de-) serialization, although the OpenAPI specification defines a concrete format.

[czechboy0]

@yanniks Our approach has been to use platform-specific types when they exist, and otherwise let developers solve it on their side. Unfortunately, I don't think there's a "date" (no time) type in the Swift standard library or Foundation, and I'd prefer we don't try to invent one, so keeping it as the string that arrives in JSON is the right call for now.

Parsing it as Date is a bug, it was never meant to be this way. A contribution with the fix is always welcome 🙂

[yanniks]

@czechboy0 Okay, got it! I'll provide a PR that changes this behavior.

By the way: when talking about platform-specific types, is there a specific reason why UUIDs are not represented as Foundation.UUID objects?

[czechboy0]

Technically, format: uuid isn't part of the OpenAPI 3.0.3 specification, it's just a convention people use, like format: email. We haven't felt we needed to support it yet, for that reason, but I also believe that UUID is defined well enough that it'd be a reasonable thing to do.