Hi Pitiphong,
Thanks for taking the time and energy to pitch this, too! If we can find
a good solution for matching this up with ISO 8601, and we have high
demand for this feature, I think it will be worth reconsidering again in
the future.
Thanks for the input!
— Itai
On 8 Sep 2017, at
Hi Itai,
As I told you in my last email that I’m thinking about the ISO 8601 case. After
thinking about that, having a discussion in the Swift Evolution and reading
your emails, I think it may not worth to add this into Swift Standard Library.
I think the use case is not that much so it’s not
Hi Itai,
Thanks for a good and solid explanation. First I want to express my use case
that was the reason I try to pitch this idea. We have a schedule service and
the data model that represent the occurrence holds an information on what date
of this occurrence was created in terms of a date
Hi Pitiphong,
Don’t worry — your original email was clear, and we are on the same
page about `Date{En,De}codingStrategy` and
`DateComponents{En,De}codingStrategy` being separate things.
To clarify my points, though, there are two main things I want to say:
1. I think there is a mismatch here
Hi Itai,
I think my first pitch email was not clear enough and want to sorry for that. I
have been working on a calendar app for awhile and understand the concept of
calendar or date and time programming in some level. I didn’t pitch the idea of
encoding and decoding `Date` value with this
Hi Pitiphong,
Thanks for pitching this! My main question here is about the use case.
Since encoding/decoding strategies apply to all values in a payload
(whether or not those belong to types that you own), they inherently
come with some risk.
What is the use case in mind for needing to encode
