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

[Itai Ferber]

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) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170905/429f912d/attachment.html>