Comment utiliser Joda-temps avec java.sql.Timestamp

Question

J'Ai une requête préparée

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 en java.sql.Timestamp. J'ai lu le Joda-Time docs et ne vois pas de référence à la présente.

Merci.

Answer 1

Vous pouvez convertir un Joda DateTime en un long (millis depuis l’époque) d’abord, puis créer un horodatage à partir de celui-ci.

 DateTime dateTime = new DateTime();
Timestamp timeStamp = new Timestamp(dateTime.getMillis());
 

Answer 2

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.L'UTC.

<Didactique De 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 De 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")
    .parse(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")
    .parse(resultSet.getString(1));

Bonus: DateTimeFormat#forPattern statiquement les caches des analyseurs par le modèle de sorte que vous n'avez pas à.

<Didactique De 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. (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 De 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.