[swift-corelibs-dev] [swift-evolution] Proposal: Conforming NSDate to Comparable

[Kevin Ballard]

On Sat, Dec 5, 2015, at 11:29 PM, Zachary Waldowski via swift-corelibs-dev wrote:
>> It is simply not the case that *all* arithmetic on NSDates is
>> incorrect unless it involves NSCalendar and NSDateComponents.
> But then the same logic would follow that String must have all sorts
> of convenient but incorrect API on it, because it is simply not the
> case that all character transformations are incorrect unless they
> involve Unicode translation. The standard libraries should not go out
> of their way to make flawed code look easy.

This doesn't make sense.

NSDate exists independently of calendars. It represents a point in time,
no more, no less. It has no notion of days or hours or anything else
larger than 1 second. It has methods to advance by a given interval, and
to calculate an interval from two dates. It also has methods for
comparing dates. All of this is perfectly valid and correct and using
them is not flawed.

I can think of no reason why declaring conformance on NSDate for
Comparable or Strideable should change any of this. All it does is
provide the standardized API that calls through to the methods that
already exist. Strideable and Comparable do not have any inherent notion
of calendars either.

It's certainly true that it is an error for a programmer to add 86400
seconds to a given NSDate and expect to get the exact same time in the
following day. But that holds true whether they're calling
.advancedBy() or whether they're calling .dateByAddingTimeInterval().
And there's plenty of valid use-cases for performing arithmetic on
dates beyond adding and subtracting days. If you want to do day
calculations, by all means use NSCalendar. That's what it's for. But
that shouldn't stop anyone else from doing their own time calculations
using the standard API.

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151206/48a1c966/attachment.html>