This works with or without milliseconds because it ignores the time portion of the string. That is, your resulting
Date will always have time at
.withFullTime brings us back to matching either with or without milliseconds again.
Im having the same issue and i've solved it the same way as above. Im curious though what backend apis are written in in these cases. They are all .net backend apis i bet. that's what i've seen the most non standard stuff with.
Only hope to get this fixed is to ensure the
swift-foundation rewrite increases compatibility. I don't think they've implemented
DateFormatter publicly yet but some of the tools are there, so hopefully we can see the implementation before it goes public.
I made a ticket on the swift foundation github to get some attention to this.
Hopefully we get a fix for it there at the very least.
I want to throw in some other specifity:
As far as I understood "date only" (without time) is also ISO/RFC compliant.
The ISO decoding strategy cannot handle this case either.
Some services don't want to represent time in a date and represent dates using the ISO format, but Swift can't handle that without modifications.
Apparently the standard is much more generic than just one type of string representation in JSON, so I think the name "
iso8601" for the decoding stategy is too generic.
We should have different strict formats for "iso8601" and also lenient variants.