Quand est-ce que dateByAddingComponents: toDate: options renvoient nil?

Question

J'utilise dateByAddingComponents:toDate:options: et dateByAddingUnit:value:toDate:options: et j'utilise la liaison facultative pour extraire la date. Comme ceci:

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

Où oneMonthComponent est juste un NSDateComponent avec la valeur du mois à 1.

Quand je lis à ce sujet, dans la documentation ils ont tous deux dire quelque chose comme:

Retours nul si la date tombe en dehors de la plage définie du récepteur ou si le calcul ne peut pas être effectué.

Et je me demandais, quand est-ce exactement causé. Si j'ajoute juste un mois à une date, y a-t-il un moyen qui pourrait être nul? Est-ce parce que certaines différences dans les autres systèmes calendriers, où l'ajout de certaines unités n'a pas de sens?

J'ai cherché autour et j'ai été incapable de trouver une instance où il retournerait zéro.

Y a-t-il quelque chose qui pourrait rendre le code ci-dessus nul? Quel est un exemple où l'ajout de composants pourrait être nul?

Answer 1

En pratique, si vous ajoutez juste un mois à une date, vous n'obtiendrez pas les valeurs nil.

Vous pouvez, cependant, obtenir une valeur nil dans certaines situations dégénérées. Par exemple, si vous utilisez le calendrier islamique et ajoutez -9 999 999 années, vous obtiendrez un nil (bien que, curieusement, pas dans d'autres calendriers). Les autres calendriers débordent souvent/enveloppent l'année dans ces situations extrêmes (même si vous vous attendez à ce qu'ils retournent nil, étant donné la documentation que vous citez).

Personnellement, je suppose qu'il existe actuellement très peu de situations dans lesquelles vous obtiendrez des valeurs nil. J'ai essayé toutes sortes de valeurs extrêmes et le calendrier islamique était le seul que j'ai réussi à obtenir une valeur nil. Cependant, cela ne signifie pas qu'Apple pourrait ne pas ajouter de logique de validation de date plus robuste à l'avenir. Nous aurions probablement besoin d'un avocat d'Apple (ou voir le code source pour NSCalendar) pour répondre à cette question définitivement. Donc, dernière ligne, je suggère de garder votre déclaration guard, mais il est peu probable d'échouer dans des scénarios du monde réel.