Comment utiliser Joda-Time avec java.sql.Timestamp

J'Ai un déclaration préparée à l'avance

INSERT INTO mst(time) VALUES (?);

où le temps est de type Timestamp dans un PostgreSQL base de données.

Je suis de l'insertion d'une Joda-Time DateTime objet, ou, devrais-je dire que je suis en train de. Je ne trouve pas de moyen de convertir l'objet DateTime dans un java.sql.Timestamp. J'ai lu le Joda-Time docs et ne vois pas de référence à la présente.

Grâce.

InformationsquelleAutor WolfmanDragon | 2009-07-01

89

Vous pouvez convertir un Joda DateTime pour une longue (millis depuis l'époque) d'abord, puis de créer un Timestamp à partir de cela.
```
DateTime dateTime = new DateTime();
Timestamp timeStamp = new Timestamp(dateTime.getMillis());
```
- Où sur le Fuseau horaire composant ? Vous avez seulement "copié" la date et l'heure mais pas le fuseau horaire qui peut affecter la valeur réelle...
- Pourriez-vous élaborer sur ce que vous voulez dire? dateTime.getMillis() retourne le nombre de millisecondes depuis le temps, qui prend le fuseau horaire en compte.
- Il est intéressant de noter que joda-temps n'a pas de magasin de nanosecondes alors que d'Horodatage ne. La conversion entre les deux perdra une précision à la nanoseconde.
- Toute solution qui préserve le fuseau horaire d'origine de la valeur?
- Comme je l'ai demandé avant, pourriez-vous préciser ce que vous entendez?
- Leow Ce qu'il veut dire, c'est que si le DateTime a un fuseau horaire qui rend le changement de date de jour à minuit, puis à l'aide d'un timestamp qui perd le fuseau horaire obtient la date de revenir en arrière dans le temps d'une journée. Et c'est la façon dont vous avez DAO tests unitaires qui ne parviennent pas uniquement autour de minuit 🙂
- Oui, si vous vivez en Nouvelle-Zélande, ce qui peut conduire à un logiciel qui échoue de manière fiable tous les matins, et fonctionne correctement tous les après-midi. Je parle par expérience personnelle, lorsque je travaillais principalement l'après-midi, et j'ai été jumelé avec un testeur qui ne travaille que le matin.
- Il n'y a aucun moyen de spécifier le fuseau horaire pour JDBC types date/heure, même lorsque la cible de la base de données prend en charge. C'est parce que tous les types sont dérivées à partir de java.util.Date qui est "cassé" à cet égard. Si vous avez besoin d'informations de fuseau horaire, je suggère d'ajouter une deuxième colonne de la base de données qui contient la TZ et enregistrer tous les points dans le temps, comme s'ils étaient en UTC. Alternativement, vous pouvez utiliser SQL natif de la syntaxe, mais ensuite, il vous faudra convertir les types de vous-même à ce que le natif SQL attend.
- Pour la postérité, si vous avez besoin de les convertir à partir d'un Timestamp à un Joda DateTime, new DateTime(timeStamp.getTime()).
- Notez que si votre DateTime est en cours d'exécution dans un autre fuseau horaire (dire UTC), puis votre nouveau Timestamp sera remis à votre propre fuseau horaire, qui peut rapporter des bugs.
- Nous pouvons abandonner l'appel à getTime dans votre suggestion à Joda-Time version 2.3. Simplement passer le java.sql.Horodatage de l'objet DateTime constructeur, comme ceci: new DateTime( timeStamp ), si une meilleure pratique serait de spécifier un fuseau horaire comme ceci: new DateTime( timeStamp, DateTimeZone.UTC ) Voir le frère de réponse par KarlKFI.
- MÉFIEZ-vous. new Timestamp() utilise en interne java Calendar, qui est initialisé avec local env fuseau horaire. Ainsi, lorsque vous ajoutez ce timestamp d'une requête à un serveur, il envoie année/mois/jour/etc, pas de nanos. Donc, si vous stockez vos horodatages UTC sur le serveur (comme beaucoup de gens le font, et MySQL ne peut stocker en UTC), ce code ne fonctionnera pas correctement -- le TIMESTAMP envoyé au serveur noterons différents instantanée (différents millisecondes) que ce qui était dans votre Joda DateTime.
InformationsquelleAutor Jack Leow
10

JodaTime de DateTime constructeur peut s'en occuper maintenant.
(Je ne suis pas sûr si c'était vrai lorsque la question a été posté, mais c'est un haut de résultats sur Google alors j'ai pensé ajouter une nouvelle solution).

Il y a quelques options de l'API:
```
public DateTime(Object instant);
public DateTime(Object instant, DateTimeZone zone);
```
Les deux options accepter java.sql.Timestamp car il s'étend java.util.Date, mais le Nanosecondes seront ignorées (parqueté), parce que DateTime et la Date ont milliseconde*. En l'absence d'un fuseau horaire, il sera par défaut à DateTimeZone.UTC.

<Didactique Mode>

"Résolution" est combien de chiffres sont fournis. "Précision" est le degré de précision de la représentation. Par exemple, MSSQL du DateTime a milliseconde, mais seulement environ 1/3 de seconde précision (DateTime2 est variable résolution et une plus grande précision).

</Didactique Mode>

UTC Timestamp avec Milliseconde Exemple:
```
new DateTime(resultSet.getTimestamp(1));
```
Si vous êtes à l'aide d'HORODATAGE AVEC le fuseau HORAIRE dans votre base de données, alors vous ne pouvez pas utiliser java.sql.Timestamp, car il ne prend pas en charge les fuseaux horaires. Vous devrez utiliser un jeu de résultats#getString et analyser la chaîne.

Timestamp sans fuseau Horaire avec la Deuxième Résolution de l'Exemple**:
```
LocalDateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss")
    .parseLocalDateTime(resultSet.getString(1));
```
UTC Timestamp avec la Deuxième Résolution de l'Exemple**:
```
DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss")
    .parseDateTime(resultSet.getString(1));
```
Timestamp avec fuseau Horaire (décalage format) avec la Deuxième Résolution de l'Exemple**:
```
DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss Z")
    .parseDateTime(resultSet.getString(1));
```
Bonus: DateTimeFormat#forPattern statiquement les caches des analyseurs par le modèle de sorte que vous n'avez pas à.

<Didactique Mode>

Je recommande généralement à l'aide d'une Chaîne de caractères dans votre DBO modèle afin de faire la résolution explicite et éviter de générer des objets intermédiaires. (Est 2013-11-14 09:55:25 égal à 2013-11-14 09:55:25.000?) En général j'ai essayer de faire la distinction entre le "modèle de base de données objets" optimisation pour la préservation des données de préoccupations et de modèle d'affaires "objets" de l'optimisation des niveaux de service l'utilisation d'une transformation/couche de mappage entre les deux. Je trouve d'avoir CRUD en fonction DAOs générer des objets directement a tendance à mélanger les priorités et les optimiser pour les deux, lancer des exceptions à des endroits inattendus en raison de manquer des cas limites. Ayant explicite de la transformation de la couche vous permet également d'ajouter de la validation si nécessaire, comme si vous n'avez pas le contrôle de la source de données. Séparer les préoccupations rend également plus facile à tester chaque couche indépendamment.

</Didactique Mode>

* Si vous avez besoin de régler à l'ordre de la nanoseconde résolution dans votre modèle d'affaires que vous aurez à utiliser une autre bibliothèque.

** Timestamp format de Chaîne de caractères peut varier entre les bases de données, pas sûr.
- Concernant nanosecondes... pour info, JSR 310: la Date et l'Heure de l'API en cours de construction dans Java 8, et Joda-Time successeur, en effet, de soutenir une résolution d'une. Gardez à l'esprit que de nombreux ordinateurs de l'horloge ne sont pas de garder du temps pour que la granularité. De côté: il est intéressant de noter à partir de la JSR spec: Ces classes utilisent une précision à la nanoseconde. Les classes ont une précision suffisante pour représenter tout l'ordre de la nanoseconde instant dans l'âge actuel de l'univers.
- Je souhaite qu'ils correcte de la diction dans ce spec... Java n'a aucun contrôle sur le matériel et la précision est fonction de la précision et de l'exactitude (ou 'justesse'). Les classes ont une RÉSOLUTION d'une et de taille assez de mémoire pour représenter un très grand nombre de nanosecondes.
- Quant à votre affirmation sur granularité: certains systèmes n'ont pas de résolution de l'ordre de la nanoseconde, et certains n'ont pas l'ordre de la nanoseconde presision ou l'exactitude. Système.nanoTime() probablement ajoute des zéros sur un système où le système d'exploitation ne fournit pas de l'ordre de la nanoseconde résolution, mais que seulement augmente la résolution, pas de précision, l'exactitude ou la précision. Voici la plus complète source que je peux trouver sur la terminologie: tutelman.com/golf/measure/precision.php
- Je ne comprends pas votre déclaration, If you're using TIMESTAMP WITH TIME ZONE in your database then you can't use java.sql.Timestamp. Malgré son nom trompeur, le type TIMESTAMP WITH TIME ZONE ne pas stocker les informations de fuseau horaire. Ce type estime de fuseau horaire lors de l'insertion et de la récupération d'une date de valeur en temps mais toujours stocke la valeur de l'UTC. On peut donc récupérer un TIMESTAMP WITH TIME ZONE valeur en tant que JDBC de type java.sql.Timestamp objet pour nourrir constructeur de org.joda.time.DateTime instance. J'ai testé à l'aide de la now() fonction.
- Pour info: Le Joda-Time, qui est maintenant dans mode de maintenance, conseille la migration vers le java.de temps les classes.
InformationsquelleAutor KarlKFI

Vous devez vous connecter pour publier un commentaire.