<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Itai,<div class=""><br class=""></div><div class="">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 `DateComponents{Encoding/Decoding}Strategy`. I still agree that `Date` value should be encoded/decoded with the `Date{Encoding/Decoding}Strategy`. The DateComponents{Encoding/Decoding}Strategy I pitched only apply for `DateComponents` value only.</div><div class=""><br class=""></div><div class="">About the use case, I think there are some application which store an information of a `Date` value that is not include a time value (A date of September 6th, 2017) for example a calendar app which want to store the Start and End date of an `All Day Event` with a value of DateComponents type or an alarm app which want to store just a time of the day that user want to set an recurring alarm (10:30am.)</div><div class=""><br class=""></div><div class="">The problem I found with the current implementation is that I have no control on how the DateComponents implement the conformance methods of the Encodable and Decodable protocol. This means that if I have a service that serialize those properties with a difference notation (ISO 8601 in my case) then I cannot rely on the auto synthesized implementation from the compiler and need to do a manual encoding/decoding by manually implement the Encodable and Decodable</div><div class=""><br class=""></div><div class="">Lastly, on the issue that `ISO8601` standard does not support every components in DateComponents, I still haven’t thought this though and still thinking about it. I want to pitch the idea first and would like to have a discussion/brainstorm on should we do this and how we can do it. My backup plan is doesn’t include the `iso8601` strategy but still have the `custom` strategy for those who need to apply a custom encoding/decoding strategy which will be apply to all values in a payload. Since we encode/decode a JSON from one source at a time and the encoding/decoding strategy of DateComponents of that source should be consistency throughout its types (which may be the types that I own or the types from a 3rd party service), I think this still is a valid use case for providing a custom strategy.</div><div class=""><br class=""></div><div class="">Thank you</div><div class="">— Pitiphong P.</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6 Sep BE 2560, at 00:15, Itai Ferber <<a href="mailto:iferber@apple.com" class="">iferber@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">Hi Pitiphong,</p><p dir="auto" class="">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.<br class="">
What is the use case in mind for needing to encode and decode <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">DateComponents</code> directly, as opposed to encoding and decoding a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">Date</code> instance and pulling the components you need from that?</p><p dir="auto" class="">From a correctness standpoint, I also want to point out that <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">DateComponents</code> is really just a "bag of stuff" that doesn’t necessarily mean much until converted into a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">Date</code> through a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">Calendar</code> and a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">TimeZone</code>. There is somewhat of a mismatch between this "bag of stuff" and what ISO 8601 intends to represent — an actual date and time. It’s possible to represent things in a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">DateComponents</code> that don’t really make sense for (or are not supported by) ISO-8601-formatted dates. For instance, you can have a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">DateComponents</code> which just has a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">TimeZone</code>, but ISO 8601 does not allow representing a time zone without a corresponding time. <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">DateComponents</code> also, for instance, has a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">quarter</code> component (among others) which I’m almost certain ISO 8601 has no equivalent for.</p><p dir="auto" class="">Given that conceptual mismatch, I think we’d need a very compelling use case to support this over simply using <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">Date</code>.</p><p dir="auto" class="">— Itai</p><p dir="auto" class="">On 3 Sep 2017, at 0:55, Pitiphong Phongpattranont via swift-evolution wrote:</p>
</div>
<div style="white-space:normal" class=""><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class=""><p dir="auto" class="">Hi folks, I have an idea on improving the JSON{Encoder/Decoder} to pitch.<br class="">
<br class="">
Since JSON doesn’t have a native representation for `DateComponents` like it doesn’t have for `Date` too so that there’re many ways to represent it in JSON, for example ISO 8601, UNIX timestamp, etc. for Date. There are also a few ways to represent `DateComponents` too, for example ISO 8601 (<a href="https://en.wikipedia.org/wiki/ISO_8601" style="color:#777" class="">https://en.wikipedia.org/wiki/ISO_8601</a>) also describes how to represent some of the valid date components (e.g. "2017-09-03”). Unlike what JSON{Encoder/Decoder} does to represent `Date` value with several strategy but there is no support like that for `DateComponents`.<br class="">
<br class="">
The current implementation DateComponents is to encode/decode with KeyedContainer and cannot provide a custom or ISO 8601 compatible implementation. So I think JSON{Encoder/Decoder} should have a strategy for encoding/decoding `DateComponents` just like for Date<br class="">
<br class="">
Here’s an initial `DateComponentsStrategy` strategy that I want JSON{Encoder/Decoder} I can think of now, any suggestion is welcomed.<br class="">
<br class="">
```swift<br class="">
/// The strategy to use for encoding `DateComponents` values.<br class="">
public enum DateComponentsStrategy {<br class="">
/// Defer to `Date` for choosing an encoding. This is the default strategy.<br class="">
case deferredToDateComponents<br class="">
<br class="">
/// Encode the `Date` as an ISO-8601-formatted string (in RFC 3339 format).<br class="">
case iso8601<br class="">
<br class="">
/// Encode the `Date` as a custom value encoded by the given closure.<br class="">
///<br class="">
/// If the closure fails to encode a value into the given encoder, the encoder will encode an empty automatic container in its place.<br class="">
case custom((DateComponents, Encoder) throws -> Void)<br class="">
}<br class="">
```<br class="">
<br class="">
What do you guys think about this pitch?<br class="">
<br class="">
<br class="">
Pitiphong Phongpattranont<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:#777" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote></div>
<div style="white-space:normal" class="">
</div>
</div>
</div>
</div></blockquote></div><br class=""></div></body></html>