> On 3 Sep BE 2560, at 23:19, Philippe Hausler <[email protected]> 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
>> <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
