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.
Zachary Waldowski
zach@waldowski.me
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
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.
I agree that it makes perfect sense for NSDate to implement Strideable. I actually do that already in my extensions.
The concept of NSDate and NSTimeInterval fit with the concept, the chance of misusing it doesn't increase too much with more utilities as a developer either knows what it represent or it doesn't (if it doesn't search for it).
This shouldn't be used for date computations (and here I could say the name is ambiguous), but for time computations.
On 6 Dec 2015, at 08:01, Kevin Ballard via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
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
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
I agree that it makes perfect sense for NSDate to implement Strideable. I actually do that already in my extensions.
The concept of NSDate and NSTimeInterval fit with the concept, the chance of misusing it doesn't increase too much with more utilities as a developer either knows what it represent or it doesn't (if it doesn't search for it).
This shouldn't be used for date computations (and here I could say the name is ambiguous), but for time computations.
I obviously agree. But I’d also add that it might make sense to emit a compiler warning for things that look like date math instead of time math—for instance, constants divisible by 86400 (24 hours), or maybe even 3600 (60 minutes).
Actually, this might be a good idea even when no time APIs are obviously involved. What are the chances your literal 86400 doesn’t have something to do with a date?
--
Brent Royal-Gordon
Architechies
I also agree, since all methods already exist in NSDate. Conforming it to Comparable and Strideable is just making interface more in line with Swift spirit.
On Dec 6, 2015, at 11:05 AM, Brent Royal-Gordon via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
I agree that it makes perfect sense for NSDate to implement Strideable. I actually do that already in my extensions.
The concept of NSDate and NSTimeInterval fit with the concept, the chance of misusing it doesn't increase too much with more utilities as a developer either knows what it represent or it doesn't (if it doesn't search for it).
This shouldn't be used for date computations (and here I could say the name is ambiguous), but for time computations.I obviously agree. But I’d also add that it might make sense to emit a compiler warning for things that look like date math instead of time math—for instance, constants divisible by 86400 (24 hours), or maybe even 3600 (60 minutes).
Actually, this might be a good idea even when no time APIs are obviously involved. What are the chances your literal 86400 doesn’t have something to do with a date?
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev