One domain where this happens is project planning back from a fixed end date.
The most well-known of these would be rocket launches: “T minus 10 seconds” is
exactly a negative time interval from an end date.
That being said, it’s a fairly uncommon use case and I wouldn’t change the API
to support it on an equivalent basis with normal forward date intervals. A
separate specific initializer for it might be useful, though.
- Greg
> On Jun 20, 2016, at 4:12 PM, Tony Parker via swift-corelibs-dev
> <[email protected]> wrote:
>
> Hi Dave,
>
> We had some extensive discussion about this ourselves, but we couldn’t come
> up with a compelling use case for a negative time interval. Can you describe
> how you wanted to use it?
>
> - Tony
>
>> On Jun 17, 2016, at 2:01 PM, Dave Lyon via swift-corelibs-dev
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> In attempting to use the new DateInterval value type to improve some
>> existing code, I ran in to an issue where DateIntervals cannot be "reverse"
>> intervals, which is contrary to how TimeInterval works, and somewhat
>> confusing.
>>
>> I would propose that the DateInterval value type should be able to be
>> properly initialized with any TimeInterval, as a reference date and time
>> interval are all that is actually required in order to construct a
>> DateInterval properly.
>>
>> The simplest solution might be to change the `startDate:interval:`
>> initializer to one allows for negative time intervals, such as:
>>
>> public init(withInterval: TimeInterval, fromDate: Date) {
>> self.start = Date(timeInterval: interval, since: fromDate)
>> self.duration = abs(interval)
>> }
>>
>> I believe in general it is preferable to avoid preconditions that require a
>> subset of a given input type (in this case, that TimeInterval be positive or
>> 0), and would prefer to see an API where invalid values are properly
>> converted from the given input to the documented output. E.g. the old “Be
>> generous with input, strict with output” idea.
>>
>> I hope this is the right place to bring this up, but if not I’m happy to
>> move the conversation to Radar or elsewhere.
>>
>> Thanks!
>>
>> _______________________________________________
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
> _______________________________________________
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
