Il y a deux problèmes avec ce que vous essayez de faire actuellement :
- Vous avez une faute de frappe dans la deuxième ligne de code, ce qui signifie que vos mois sont analysés en minutes
- Comme mentionné, vous ne tenez pas compte du fuseau horaire.
Pour résoudre le premier problème, vous devez modifier
Date d2 = new SimpleDateFormat("dd/mm/yyyy").parse(arr[10]);
à
Date d2 = new SimpleDateFormat("dd/MM/yyyy").parse(arr[10]);
Les formats de date sont sensibles à la casse, ce que vous essayez de faire est d'analyser le mois comme un ** m ** inute au lieu d'un ** M ** onth. Dans le test que j'ai effectué, cela signifiait que les mois sortaient tous en janvier, ce que je peux voir se produire également dans votre exemple. De plus, je remarque que votre première ligne de code, le formateur (qui est configuré correctement) n'est pas utilisé.
Le deuxième problème est que oui, Java Date s ne se comporte pas comme prévu. Ils DOIVENT avoir une composante temporelle, même si vous ne vous en souciez pas simplement pour la date. De plus, ils doivent avoir un fuseau horaire puisqu'ils ont une heure.
Vous n'aurez peut-être pas le choix de passer à la bibliothèque Joda supérieure, auquel cas il existe des moyens de contourner ce problème. J'ai écrit un test qui devrait démontrer ceci :
@Test
public void shouldParseDateCorrectly() throws Exception {
// Given
SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
format.setTimeZone(TimeZone.getTimeZone("UTC"));
// When
Date parsedDate = format.parse("21/08/2012");
// Then
Assert.assertThat(parsedDate.toString(), is("Tue Aug 21 02:00:00 CEST 2012"));
Assert.assertThat(parsedDate.toGMTString(), is("21 Aug 2012 00:00:00 GMT"));
}
Vous pouvez donc voir que j'ai utilisé le bon format, mais également défini son fuseau horaire sur UTC (il a donc un décalage de zéro et pas d'heure d'été). Ensuite, lorsque vous analysez la date avec ce formateur, la date sortira avec une heure qui correspond à minuit dans le fuseau horaire UTC. Parce que mon ordinateur est en Europe, lorsque j'imprime cette date, il affiche une heure de 2h du matin, car ce fuseau horaire a 2 heures d'avance sur UTC. Mais quand j'utilise le toGMTString obsolète méthode, le temps sort comme zéro.
Lorsque vous stockez cette date dans MongoDB à l'aide du pilote Java, il enregistre la date, l'heure et le fuseau horaire, même si tout ce qui vous intéresse est la date. Ce que vous devrez faire lorsque vous relirez les dates, c'est vous rappeler qu'elles sont en UTC et définir le fuseau horaire de manière appropriée.
Alternativement, vous pouvez les stocker dans MongoDB sans changer le fuseau horaire, à condition que vous les lisiez et les écriviez toujours dans le même fuseau horaire. Mais cela se heurte à des bogues inattendus lorsque a) le traitement des heures au-delà de minuit et b) l'heure d'été démarre (ou s'arrête).
Ou utilisez simplement Joda-Time .
