Comparer objet Date avec un TimeStamp en Java

Quand je l'ai tester ce code:

java.util.Date date = new java.util.Date();
java.util.Date stamp = new java.sql.Timestamp(date.getTime());

assertTrue(date.equals(stamp));
assertTrue(date.compareTo(stamp) == 0);
assertTrue(stamp.compareTo(date) == 0);
assertTrue(stamp.equals(date));

Mal-être attendre un vrai, vrai, vrai, faux. De ce fait:

Dans la javadoc de java.sql.Timestamp, il indique:

Remarque: Ce type est un composite de java.util.Date et un autre
nanosecondes valeur. Seulement partie intégrante secondes sont stockés dans le
java.util.Composant de Date. Les fractions de secondes - les nanos - sont
séparé. L'Horodatage.equals(Object) méthode ne retourne vrai lorsque
passé d'une valeur de type java.util.Date parce que les nanos composant d'un
la date est inconnue. En conséquence, l'Horodatage.equals(Object) la méthode est
pas symétrique par rapport à la java.util.Date.equals(Object)
la méthode. Aussi, la méthode hashcode utilise le sous-jacent de java.util.Date
la mise en œuvre et n'inclut donc pas les nanos dans son
le calcul.

En raison des différences entre le Timestamp de la classe et de l'
java.util.Classe Date mentionnée ci-dessus, il est recommandé que le code n'
affichage des valeurs d'Horodatage génériquement comme une instance de java.util.Date.
La relation d'héritage entre l'Horodatage et la java.util.Date
vraiment désigne la mise en œuvre de l'héritage, et non pas le type d'héritage.

Mais plutôt Mauvais obtenir un true, false, true, false. Des idées?

EDIT: Ce problème apparaît lorsque je vérifiais les deux Dates avec la méthode equals, mais celui de l'objet Date viennent de Hibernate classe et de débogage je vois que l'objet contient un Horodatage. Donc, la méthode equals à false, alors j'ai trouvé ceci: http://mattfleming.com/node/141

Mais quand j'ai essayer le code que j'obtiens des résultats différents...si je ne peux utiliser ni d'égal à égal et compareTo, ce que je doit utiliser pour vérifier si les 2 Dates sont les mêmes?!?!

En gros: si vous voulez comparer deux homogène des objets (soit la Date ou Timestamp), il n'y a pas de problème; il ne faut pas comparer deux objets hétéroclites. Nous pouvons essayer de résoudre le problème à la source, le sens: pourquoi avez-vous comparer?
Im la comparaison de deux objets Date, mais l'objet implicite dans l'un d'eux est un TimeStamp est un type de Date. Si l'héritage fonctionne dans un autre objet, pourquoi pas ici?
Parce que la mise en œuvre de Timestamp est stupide; vous devez traiter ces deux classes comme n'étant pas liés, tout comme l'intention de celui qui l'a écrit.

InformationsquelleAutor Torres | 2012-01-19

6

tl;dr

Utiliser le moderne java.temps classes à la place de ceux gênants héritage de date-heure classes.
```
myPreparedStatement.setObject(
    … , 
    Instant.now()                //Capture the current moment in UTC.
)
```
Vieille Date-Heure Classes Mal Conçu

Mettre plus crûment, la java.sql.Horodatage/.Date/.Du temps des classes est un hack, un mauvais hack. Comme java.util.Date/.Calendrier, ils sont le résultat d'un mauvais choix de conception.

La java.les types sql doit être utilisé, aussi brièvement que possible, utilisé seulement pour le transfert de données de la base de données. Ne pas utiliser pour la logique métier et la poursuite des travaux.

java.temps

La vieille date-heure classes ont été remplacés par les java.le temps cadre intégré dans Java 8 et les versions ultérieures. Ces nouvelles classes sont définies par la JSR 310, inspiré par la très réussie Joda-Time library, et prolongée par le ThreeTen-projet Extra.

Finalement, nous devrions voir des pilotes JDBC mis à jour à travailler directement avec ces java.les types d'heures. Mais jusqu'à ce jour nous avons besoin de les convertir vers/à partir de java.les types sql. Pour de telles conversions, appel de nouvelles méthodes ajoutées aux anciennes classes.

Un Instantané est un moment dans le scénario de l'UTC à une résolution de nanosecondes.
```
Instant instant = myJavaSqlTimestamp.toInstant();
```
Aller dans l'autre direction:
```
java.sql.Timestamp ts = java.sql.Timestamp.valueOf( instant );
```
Appliquer une zone de temps pour obtenir horloge murale.
```
ZoneId zoneId = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = ZonedDateTime.ofInstant( instant , zoneId );
```
La java.les classes de temps propre a sagement choisi de conception de classe. Ainsi, vous pouvez utiliser le equals et compareTo comme prévu. Notez que les classes avec un décalage de l'UTC ou de fuseau horaire offrent également isEqual, isBefore, et isAfter méthodes. Ces méthodes de comparer en considérant les moments sur la timeline, leur ordre chronologique. Le equals et compareTo méthodes de considérer également le décalage de temps ou de zone.

La réduction de l'utilisation de java.sql, tout en maximisant l'utilisation de java.temps, rend la Question de questions hypothétiques.

En veille prolongée, utiliser des convertisseurs pour java.temps.

JDBC 4.2

De JDBC 4.2 et versions ultérieures, vous ne devez pas utiliser l'héritage des classes à tous. Vous pouvez échanger directement des java.temps objets avec votre base de données via le getObject & setObject méthodes.
```
myPreparedStatement.setObject( … , instant ) ;
```
Et de la récupération.
```
Instant instant = myResultSet.getObject( … , Instant.class ) ;
```
Noter que de nombreuses bases de données ne peut pas stocker un moment avec une résolution aussi fine que les nanosecondes utilisé dans java.temps. Vous pouvez tronquer explicitement plutôt que de laisser votre Pilote JDBC faire implicitement.
```
Instant instant = Instant.now().truncatedTo( ChronoUnit.MILLIS ) ; //Lop off any nanoseconds & microseconds, keeping only the milliseconds, to match limitations of database. 
```
Sur java.temps

La java.temps cadre est intégré dans Java 8 et les versions ultérieures. Ces classes permettent d'éviter la pénible vieux héritage date du temps des classes comme java.util.Date, Agenda, & SimpleDateFormat.

La Joda-Time projet, maintenant dans le mode de maintenance, conseille la migration vers le java.le temps classes.

Pour en savoir plus, consultez les Oracle Tutoriel. Et de recherche de Débordement de Pile pour de nombreux exemples et des explications. La spécification est JSR 310.

Vous pouvez échanger java.temps objets directement avec votre base de données. Utiliser un Pilote JDBC compatible avec JDBC 4.2 ou plus tard. Pas besoin de chaînes, pas besoin de java.sql.* classes.

Où obtenir le java.les classes de temps?
- Java SE 8, Java SE 9, Java SE 10, et plus tard
  - Intégré.
  - Partie de la norme API Java avec une liasse de mise en œuvre.
  - Java 9 ajoute quelques fonctionnalités mineures et corrections.
- Java SE 6 et Java SE 7
  - Une grande partie de la java.fonction temps est de retour, porté à Java 6 & 7 dans ThreeTen-Backport.
- Android
  - Plus tard, des versions d'Android bundle implémentations de java.les classes de temps.
  - Antérieures d'Android (<26), le ThreeTenABP projet s'adapte ThreeTen-Backport (mentionné ci-dessus). Voir Comment utiliser ThreeTenABP....
La ThreeTen-Extra projet s'étend java.temps avec d'autres classes. Ce projet est un terrain d'essai pour de possibles futurs ajouts à java.temps. Vous pouvez trouver quelques classes utiles ici comme Intervalle, YearWeek, YearQuarter, et plus.

InformationsquelleAutor Basil Bourque
6

Nican expliqué le equals partie, sur compareTo:
- Timestamp a un compareTo(Date) méthode qui convertit Timestamp en interne
- Date la comparaison par passer (depuis Timestamp est une sous-classe de celle-ci); mais comme la javadoc unis: "La relation d'héritage entre l'Horodatage et la java.util.Date vraiment désigne la mise en œuvre de l'héritage, et pas d'héritage de type"
Qui bien sûr est une idée horrible, à mon avis.

InformationsquelleAutor Viruzzo

J'ai eu le même problème dans un essai où j'ai voulu comparer java.util.Date et java.sql.Timestamp objets.

Je les ai converti en LocalDate et ça a fonctionné:

import org.apache.commons.lang.ObjectUtils;

//date1 and date2 can be java.util.Date or java.sql.Timestamp
boolean datesAreEqual = ObjectUtils.equals(toLocalDate(date1), toLocalDate(date2));

où toLocalDate est:

import org.joda.time.LocalDate;
import java.util.Date;

public static void LocalDate toLocalDate(Date date)
{
    return date != null ? LocalDate.fromDateFields(date) : null;
}

InformationsquelleAutor Ferran Maylinch

3
1. date.est égal à(timbre) return true ET de timbre égal à(date) renvoie la valeur false. RAISON :Date néglige l'ordre de la nanoseconde partie de l'horodatage et depuis les autres parties arriver à être l'égal de sorte que le résultat est à la hauteur. Les fractions de secondes - les nanos - sont distinctes.L'Horodatage.equals(Object) méthode ne retourne vrai lorsqu'il est passé d'une valeur de type java.util.Date parce que les nanos composant d'une date est inconnue. Voir ici pour plus de détails
  1. date.compareTo(timbre) == 0 retourne la valeur false ET de timbre.compareTo(date) == 0 retourne la valeur true. RAISON: Selon cette bug compareTo fonction se comporte comme il le fait.
- Voir ce lien: mattfleming.com/node/141
InformationsquelleAutor Saurabh
2

Timestamp's nanos valeur n'est PAS le nombre de nanosecondes - c'est un ordre de la nanoseconde résolution numéro de millis (c'est à dire les fractions de secondes). Ainsi, dans le Timestamp constructeur, il est le réglage de l'heure sur le super sans millisecondes. Par conséquent, la Timestamp aura toujours une valeur plus faible pour le membre fastTime (utilisé en Date du compareTo()) que le correspondant de Date (à moins, bien sûr, il n'a pas de fractions de secondes).

Vérifier la source de Timestamp à la ligne 110.

InformationsquelleAutor sarumont

Essayer de recréer l'objet de la date à l'aide de "Cordes" comme ce

Date date = new Date();
Date stamp = Timestamp(date.getTime());

SimpleDateFormat ft = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
String date1String = ft.format(date);
String date2String = ft.format(stamp);

Date date1 = ft.parse(date1String);
Date date2 = ft.parse(date2String);


assertTrue(date1.equals(date2)); //true
assertTrue(date1.compareTo(date2) == 0); //true
assertTrue(date2.compareTo(date1) == 0); //true
assertTrue(date2.equals(date1)); //true

InformationsquelleAutor Marco Mendão

J'ai résolu la conversion à la fois la Date et l'Horodatage dans un Calendrier de l'objet, puis j'ai comparé le seul Calendrier propriétés:

Calendar date = Calendar.getInstance();
date.setTimeInMillis(dateObject.getTime());
Calendar timestamp = Calendar.getInstance();
timestamp.setTimeInMillis(timestampObject.getTime());
if (effettoAppendice.get(Calendar.DAY_OF_MONTH) == timestamp.get(Calendar.DAY_OF_MONTH) &&
    effettoAppendice.get(Calendar.MONTH) == timestamp.get(Calendar.MONTH) &&
    effettoAppendice.get(Calendar.YEAR) == timestamp.get(Calendar.YEAR)) {
    System.out.println("Date and Timestamp are the same");
} else {
    System.out.println("Date and Timestamp are NOT the same");
}

Espère que cette aide.

InformationsquelleAutor Pasquale Ciuffreda

0

Prendre un coup d'oeil au code source de la méthode de comparaison pour l'Horodatage:
```
public boolean equals(java.lang.Object ts) {
  if (ts instanceof Timestamp) {
    return this.equals((Timestamp)ts);
  } else {
    return false;
  }
}
```
http://www.docjar.com/html/api/java/sql/Timestamp.java.html

Il ne retourne true si la comparaison de l'objet est un timestamp.
Aussi, ici, est la Date à laquelle le code source: http://www.docjar.com/html/api/java/util/Date.java.html , et depuis Timestamp hérite Date, il est possible de le comparer.
- L'affirmation fausse, il se préoccupe de l'est compareTo(), pas equals().
InformationsquelleAutor Nican
0

Malheureusement, la Timestamp classe ne surcharge le equals(Object) méthode avec equals(Timestamp) donc des comparaisons sur les Horodateurs sont difficiles à faire.

Dans le equals(Object) javadocs dit:

Des Tests pour voir si ce Timestamp objet est
égal à l'objet donné. Cette version de la méthode equals a été
ajoutée pour résoudre la signature incorrecte de Timestamp.equals(Timestamp)
et pour préserver arrière la compatibilité avec les fichiers de classe.
Remarque: Cette méthode n'est pas symétrique par rapport à la equals(Object)
méthode dans la classe de base.

Ma règle d'or est de ne jamais comparer les horodatages pour l'égalité (qui est à peu près inutile de toute façon), mais si vous avez à vérifier l'égalité, de les comparer en utilisant le résultat de getTime() (le nombre de millisecondes depuis le 1er janvier 1970, 00:00).
- Pourquoi "malheureusement"? Les Classes sont censés fournir un véritable equals() mise en œuvre, de ne pas utiliser celui par défaut qui est ignorant de la valeur de données réelles.
- Ce faisant, il rompt le contrat, d'égal à égal: une date est égale à un timestamp, mais un horodatage n'est pas égale à une date. Ils ne devraient pas avoir une relation d'héritage entre les classes. Et ils doivent avoir été immuable.
- Je suis d'accord sur les deux devraient l'; encore, il n'y a rien de mal (c'est en fait mieux) en fournissant un plus spécifiques à remplacer d'égal à égal. Une chaîne trop a compareTo(String), comme ne Entier et ainsi de suite.
- Malheureusement, parce que jusqu'à Java 1.1 de l'API uniquement mis en œuvre que la equals(Timestamp) de la méthode, et de 1,2 ils ont ajouté la equals(Object). N'est généralement pas une bonne idée de la surcharge de la méthode equals (), spécialement sur le precense de l'héritage (ce qui implique qu'est égal sera PAS symétrique). Donc, c'est juste la classe a été mis en œuvre et a évolué au fil du temps afin de conserver sa fonction d'origine et de ne pas briser actuel code du travail.
- Oui, mais la Chaîne de caractères, Entier, etc. le faire sans violer les égaux contrat. Et ils remplacent Object's est égal à la mise en œuvre. Timestamp remplace Date's est égal à la mise en œuvre.
- il n'y a rien de mal sur la substitution equals() toutefois surcharger avez des problèmes décrits précédemment. Le Comparable<T> interface est encore plus strictes sur la mathématique des contraintes sur leurs éléments de la norme des collections triées de fonctionner correctement (comme le représentant de l'élément dans un ordre déterminé, et d'être compatible avec equals(), mais equals() n'est même pas symétrique).
- Je suis d'accord que Timestamp.equals(Date) est une mauvaise idée (du moins tel qu'il est mis en œuvre), mais la réponse se réfère à Timestamp.equals(Timestamp).
InformationsquelleAutor Gabriel Belingueres
0

Une Petite note sur Implementaion de succession et d'héritage de Type..

"Un objet de la classe définit la manière dont l'objet est mis en œuvre. En revanche, un type de l'objet ne se réfère qu'à son interface. L'héritage de classe(mise en Œuvre de l'héritage) définit un objet de la mise en œuvre en termes d'un autre objet de la mise en œuvre. Type de l'héritage décrit lorsqu'un objet peut être utilisé à la place de l'autre."

L'horodatage et la Date de classes de mise en œuvre de l'héritage comme JAVADOC dit.

InformationsquelleAutor Shanmugavel

Vous devez vous connecter pour publier un commentaire.

tl;dr

Vieille Date-Heure Classes Mal Conçu

java.temps

JDBC 4.2

Sur java.temps