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

[Pitiphong Phongpattranont]

> On 3 Sep BE 2560, at 23:19, Philippe Hausler <phausler at apple.com> wrote:
> 
> So you are suggesting to use the iso8601 calendar but what timezone? Iirc there are some date components that are not representable in a conversion to iso8601 because of quirks with daylight savings and time zones. The other issue is that the value would not round trip: say I stored a DateComponents with the Gregorian calendar and the timezone for americas/Los Angeles that would mean that when it would be serialized it would loose that information and be deserialized as iso8601 calendar with GMT-8.
> 

Nope, what I’m proposing is just for a `DateComponents` that has only some components value but not a complete date-time value, for example a calendar date only components (“2017-09-03”) or a time of the day only components ("23:59:59”). On the calendar, since ISO 8601 supports Gregorian calendar only, I suggest we should throw and encoding error out to tell the user. For the last concern, “timezone” I still don’t have a better solution but if user really want to preserve the timezone information then they can use the `custom` strategy

> 
>> On Sep 3, 2017, at 12:54 AM, Pitiphong Phongpattranont via swift-evolution <swift-evolution at swift.org> 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