Fin du mois suivant

Il gère février, les années bissextiles, les mois de trente ou trente et un jours ainsi que le passage de décembre à janvier, sans dépendre de l’horloge ni du fuseau horaire de l’appareil. Utilisez-le lorsqu’une règle de facturation, une période de rapport, un avis de renouvellement ou un workflow exige une date ISO stable, reproductible dans un navigateur, une intégration API ou une suite de tests.

Déterminez une limite claire pour le mois suivant

De nombreuses règles métier semblent simples jusqu’au franchissement d’une limite mensuelle. La consigne « poursuivre jusqu’à la fin du mois suivant » ne peut pas être traduite par l’ajout d’un nombre fixe de jours, car les mois civils en comptent vingt-huit, vingt-neuf, trente ou trente et un. Ce calculateur part du mois contenu dans la date ISO fournie, avance d’un mois civil exactement, puis choisit le dernier jour valide de ce mois cible. Une date de janvier conduit donc à la fin de février, tandis qu’une date de novembre conduit à la fin de décembre. Le jour de la date initiale ne modifie pas la limite obtenue, mais il reste validé afin qu’une date impossible ne se glisse pas silencieusement dans un traitement. Le résultat est une date ISO utilisable dans des champs de base de données, des tâches planifiées, des factures, des rapports et tout système nécessitant une valeur sans ambiguïté. Le calcul suit le calendrier grégorien proleptique et donne toujours la même réponse pour une même entrée valide.

Maîtrisez les années bissextiles et le changement d’année

Février est le mois où les raccourcis échouent le plus souvent. Dans le calendrier grégorien, une année est bissextile lorsqu’elle est divisible par quatre, sauf pour les années séculaires, qui doivent aussi être divisibles par quatre cents. Février 2024 compte donc vingt-neuf jours, février 2100 en compte vingt-huit et février 2000 en compte vingt-neuf. Le calculateur applique directement cette règle avec des nombres entiers. Il traite également le passage de décembre à janvier en augmentant l’année : une entrée de décembre 2026 renvoie le dernier jour de janvier 2027. L’entrée doit comporter une véritable année à quatre chiffres entre 0001 et 9999, un mois sur deux chiffres et un jour sur deux chiffres. Le jour doit exister dans le mois concerné ; le 31 avril et le 29 février d’une année commune sont refusés. Si décembre 9999 impose de dépasser la plage ISO à quatre chiffres prise en charge, la requête est rejetée au lieu de produire une valeur incorrecte ou ambiguë.

Employez un calcul de dates déterministe et sûr en UTC

Un calcul de date peut se décaler lorsqu’un logiciel interprète minuit dans un fuseau horaire puis reformate la valeur dans un autre. Cette capacité écarte toute cette catégorie d’erreurs. Elle ne lit pas l’heure courante, n’instancie aucun objet Date, n’utilise pas le fuseau du système, ne contacte aucun service réseau et ne génère aucune valeur aléatoire. Elle extrait plutôt l’année, le mois et le jour écrits, puis effectue un calcul grégorien borné sur ces entiers. Cette conception est sûre vis-à-vis d’UTC puisqu’aucun décalage local n’intervient. La même entrée envoyée depuis un navigateur à Tokyo, un serveur à New York ou un exécuteur de tests réglé sur UTC conserve exactement la même date. Pour une automatisation, validez le champ end_of_next_month renvoyé comme date ISO et stockez-le directement si le contrat en aval emploie une borne de fin de mois inclusive. Si un autre système attend une borne exclusive, adaptez le résultat selon sa convention documentée au lieu de supposer que « fin de mois » désigne le premier instant du lendemain.