`uuuu 'contre `yyyy 'dans' DateTimeFormatter ' formatage des codes de modèle en Java?

Dans la section javadoc Patterns pour le formatage et l'analyse pour DateTimeFormatter, il répertorie les 3 symboles pertinents suivants:

Symbol  Meaning        Presentation  Examples
------  -------        ------------  -------
 G       era            text          AD; Anno Domini; A
 u       year           year          2004; 04
 y       year-of-era    year          2004; 04

Juste pour comparaison, ces autres symboles sont assez faciles à comprendre:

 D       day-of-year    number        189
 d       day-of-month   number        10
 E       day-of-week    text          Tue; Tuesday; T

Le day-of-year, day-of-month, et day-of-week sont les jour à l'intérieur de l'étendue donnée (année, mois, semaine).

Donc, year-of-era signifie l'année dans la portée donnée (era), et juste au-dessus era est montré avec une valeur d'exemple de AD (l'autre valeur étant bien sûr BC).

year est le signée année, lorsque l'année 0 est 1 BC, year -1 est 2 BC, et ainsi de suite.

Pour illustrer: Quand Jules César a-t-il été assassiné ?

• , le 15 Mars 44 avant j.-c. (utilisant le modèle MMMM d, y GG)
• 15 mars -43 (en utilisant le motif MMMM d, u)

La distinction n'aura bien sûr d'importance que si l'année est nulle ou négative, et comme c'est rare, la plupart des gens s'en moquent, même bien qu'ils le devraient.

Conclusion: Si vous utilisez y, vous devez également utiliser G. Comme G est rarement utilisé, le symbole correct de l'année est u, pas y, sinon une année non positive s'affichera incorrectement.

Ceci est connu comme défensive de programmation:

La programmation défensive est une forme de conception défensive destinée à assurer le fonctionnement continu{[58] } d'un logiciel en cas d'imprévu circonstances.

Remarque que DateTimeFormatter est cohérente avec SimpleDateFormat:

Letter  Date or Time Component  Presentation  Examples
------  ----------------------  ------------  --------
G       Era designator          Text          AD
y       Year                    Year          1996; 96

Les années négatives ont toujours été un problème, et ils l'ont maintenant corrigé en ajoutant u.

Longue histoire courte

1. Dans 99% des cas, vous pouvez lancer une pièce, cela ne fera aucune différence si vous utilisez yyyy ou uuuu (ou si vous utilisez yy ou uu pour une année à 2 chiffres).
2. Cela dépend de ce que vous voulez arriver au cas où un an plus tôt que 1 CE (1 AD) se produirait. Le fait est que dans 99% des programmes, une telle année ne se produira jamais.

Deux autres réponses ont déjà présenté les faits de la façon dont u et y fonctionnent très bien, mais je me sentais toujours il manquait quelque chose, donc je contribue à la réponse légèrement plus basée sur l'opinion.

Pour le formatage

En supposant que vous ne vous attendez pas à ce que 1 CE soit formaté un an avant, la meilleure chose à faire est de vérifier cette hypothèse et de réagir de manière appropriée au cas où elle se briserait. Par exemple, selon les circonstances et les exigences, vous pouvez imprimer un message d'erreur ou lancer une exception. Un très doux échec chemin d'accès peut être d'utiliser un modèle avec y (année de l'ère) et G (ère) en ce cas et un modèle avec u ou y dans le cas normal et actuel de l'ère. Notez que si vous imprimez la date actuelle ou la date à laquelle votre programme a été compilé, vous pouvez être sûr qu'il est dans l'ère commune et peut choisir d'ignorer la vérification.

Pour l'analyse

Dans beaucoup (la plupart?) l'analyse des cas signifie également la validation, ce qui signifie que vous n'avez aucune garantie à quoi ressemble votre chaîne d'entrée. Généralement il s'agit de l'utilisateur ou d'un autre système. Un exemple: une chaîne de date se présente sous la forme 2018-09-29. Ici, le choix entre uuuu et yyyy devrait dépendre de ce que vous voulez arriver dans le cas où la chaîne contient une année de 0 ou négative (par exemple, 0000-08-17 ou -012-11-13). En supposant que ce serait une erreur, la réponse immédiate est: utilisez yyyy pour qu'une exception soit levée dans ce cas. Encore plus fin: utilisez uuuu et après l'analyse, effectuez une vérification de la plage de la date analysée. Cette dernière approche permet à la fois une validation plus fine et un meilleur message d'erreur en cas de validation erreur.

Cas particulier (déjà mentionné par Meno Hochschild): Si votre formateur utilise un style de résolveur strict et contient y sans G, l'analyse échouera toujours car à proprement parler, l'année de l'ère est ambiguë sans ère: 1950 peut signifier 1950 CE ou 1950 BCE (1950 BC). Donc, dans ce cas, vous avez besoin de u (ou de fournir une ère par défaut, cela est possible via un DateTimeFormatterBuilder).

Longue histoire courte encore

Vérification explicite de la plage de vos dates, en particulier votre ans, c'est mieux que de compter sur le choix entre uuuu et yyyy pour attraper des années inattendues très tôt.