Noda Time vs Joda Time?

Dans le Noda Time User's Guide , la section sur la justification indique:

l'API publique a été en grande partie réécrite, à la fois pour fournir une API plus idiomatique pour .NET, et aussi pour rectifier certaines des décisions de Joda Time que l'équipe de Noda Time considère comme "malheureuses". (Certains d'entre eux sont simplement dus à des objectifs différents; d'autres, selon moi, sont vraiment des erreurs.)

Quelles sont ces décisions différentes / meilleures? Cela ne compterait pas les différences uniquement pour la syntaxe du langage, mais inclurait tout ce qui est fait pour rendre les utilisateurs moins susceptibles de faire une erreur de programmation (facilité d'utilisation de la bibliothèque).

Le meilleur endroit pour commencer est probablement la section "philosophie de conception" du guide de l'utilisateur. Mais pour exposer les différences spécifiques entre Noda Time et Joda Time:

• Noda Time conserve beaucoup plus son code interne. Cela le rend moins flexible, car vous ne pouvez pas créer votre propre système de calendrier - mais cela signifie également que l'API est plus simple à apprendre et à utiliser.

• La nullité est presque toujours une erreur dans Noda Time. Plus "si vous passez null pour un fuseau horaire, nous utiliserons simplement la valeur par défaut du système." Vous devez être explicite.

• En parlant de valeurs par défaut ... nous n'utilisons pas l'horloge système par défaut. Nous avons une IClockinterface distincte avec une SystemClockimplémentation, mais rien n'est par défaut "l'heure actuelle".

• Mis à part les classes de générateur spécifiques, tout est immuable. Je pense que MutableDateTime(et al) dans Joda Time étaient une erreur.

• Nous avons séparé le système de calendrier et le fuseau horaire les uns des autres, car ce sont des préoccupations très différentes. Ainsi, un LocalDateconnaît le système de calendrier qu'il utilise, mais pas le fuseau horaire, par exemple.

• La manière de résoudre les valeurs de date / heure locales en valeurs de date / heure zonées est plus proche de JSR-310 que de Joda Time. Nous ne nous contentons pas de gérer l'ambiguïté / les temps ignorés d'une manière particulière: nous faisons dire à l'utilisateur ce qu'il veut.

• Joda Time a plusieurs endroits où il essaie de deviner ce que vous voulez d'une API faiblement typée (par exemple nouvelle Instant(Object)). Noda Time évite cela autant que possible - c'est beaucoup plus explicite.

• Noda Time est plus strict dans le type d'arithmétique que vous pouvez effectuer sur quels types. Ainsi, par exemple, vous ne pouvez pas ajouter un Periodà un ZonedDateTime, car il existe des bizarreries autour des transitions d'heure d'été qui pourraient gâcher les choses. Au lieu de cela, nous encourageons les utilisateurs à se convertir LocalDateTime, à effectuer autant d'arithmétiques qu'ils le souhaitent dans un contexte non zoné, puis à reconvertir.

• Noda Time utilise l'héritage plutôt moins - les hiérarchies dans Joda Time sont extrêmement profondes et compliquées. Le fait que beaucoup de Noda Time soit basé sur des types de valeurs l'impose en fait de toute façon, mais il y a des endroits où nous utilisons toujours l'héritage de classe, mais j'ai réussi à réduire la hiérarchie d'héritage de manière significative ... souvent au détriment de flexibilité que je n'ai pas jugé utile :)