[swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Tue Sep 5 12:41:33 CDT 2017

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 `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.

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.)

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

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.

Thank you
— Pitiphong P.

> On 6 Sep BE 2560, at 00:15, Itai Ferber <iferber at apple.com> wrote:
> 
> 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 and decode DateComponents directly, as opposed to encoding and decoding a Date instance and pulling the components you need from that?
> 
> From a correctness standpoint, I also want to point out that DateComponents is really just a "bag of stuff" that doesn’t necessarily mean much until converted into a Date through a Calendar and a TimeZone. 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 DateComponents that don’t really make sense for (or are not supported by) ISO-8601-formatted dates. For instance, you can have a DateComponents which just has a TimeZone, but ISO 8601 does not allow representing a time zone without a corresponding time. DateComponents also, for instance, has a quarter component (among others) which I’m almost certain ISO 8601 has no equivalent for.
> 
> Given that conceptual mismatch, I think we’d need a very compelling use case to support this over simply using Date.
> 
> — Itai
> 
> On 3 Sep 2017, at 0:55, Pitiphong Phongpattranont via swift-evolution wrote:
> 
> Hi folks, I have an idea on improving the JSON{Encoder/Decoder} to pitch.
> 
> 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 (https://en.wikipedia.org/wiki/ISO_8601 <https://en.wikipedia.org/wiki/ISO_8601>) 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`.
> 
> 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
> 
> Here’s an initial `DateComponentsStrategy` strategy that I want JSON{Encoder/Decoder} I can think of now, any suggestion is welcomed.
> 
> ```swift
> /// The strategy to use for encoding `DateComponents` values.
> public enum DateComponentsStrategy {
> /// Defer to `Date` for choosing an encoding. This is the default strategy.
> case deferredToDateComponents
> 
> /// Encode the `Date` as an ISO-8601-formatted string (in RFC 3339 format).
> case iso8601
> 
> /// Encode the `Date` as a custom value encoded by the given closure.
> ///
> /// If the closure fails to encode a value into the given encoder, the encoder will encode an empty automatic container in its place.
> case custom((DateComponents, Encoder) throws -> Void)
> }
> ```
> 
> What do you guys think about this pitch?
> 
> 
> Pitiphong Phongpattranont
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170906/35268cf3/attachment.html>