Когда dateByAddingComponents: toDate: options return nil?

Question

Я использую dateByAddingComponents:toDate:options: и dateByAddingUnit:value:toDate:options: и используя необязательное связывание, чтобы получить дату из него. Как это:

guard let startOfNextMonth = calendar.dateByAddingComponents(oneMonthComponent, toDate: startOfThisMonth, options: []) else { 
    return nil 
} 

Где oneMonthComponent это просто NSDateComponent со значением месяца равным 1.

Когда я прочитал об этом в документации они оба говорят что-то вроде:

возвратов nil, если дата выходит за пределы определенного диапазона приемника или если вычисление не может быть выполнено.

И мне было интересно, когда это точно вызвано. Если я просто добавлю месяц к дате, есть ли способ, который может когда-либо быть нулевым? Это потому, что некоторые различия в других календарных системах, где добавление некоторых единиц не имеет смысла?

Я искал вокруг и не смог найти экземпляр, где он будет возвращать нуль.

Есть ли что-нибудь, что могло бы сделать код выше, ноль? Что такое пример, когда добавление компонентов может быть нулевым?

Answer 1

На практике, если вы просто добавляете месяц к дате, вы не получите значений nil.

Вы можете, однако, получить значение nil в некоторых дегенеративных ситуациях. Например, если вы используете исламский календарь и добавляете -9,999,999 лет, вы получите nil (хотя, что любопытно, а не в других календарях). Другие календари часто переполняют/завершают год в этих экстремальных ситуациях (хотя вы ожидаете, что они вернут nil, учитывая приведенную вами документацию).

Лично я подозреваю, что в настоящее время очень мало ситуаций, в которых вы получите nil значений. Я пробовал всевозможные экстремальные ценности, и исламский календарь был единственным, что мне удалось получить значение nil. Однако это не означает, что Apple может не добавить более надежную логику проверки даты в будущем. Нам, вероятно, придется получить совет от Apple (или посмотреть исходный код для NSCalendar), чтобы окончательно ответить на этот вопрос.

Итак, в нижней строке, я бы предложил оставить ваш guard заявление, но вряд ли он потерпит неудачу в реальных сценариях.