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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
