Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[JAVA] FlightSQL JDBC Driver PreparedStatement#setTimestamp() ignores connection timeStampPrecision

Ouverte
#838 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
java
Domaine
databases

Piste de recherche

Commencez par suivre PreparedStatement#setTimestamp et setTimestamp pour timestamptz jusqu’à DateTimeUtils#sqlTimestampToUnixTimestamp(Timestamp, TimeZone), puis examinez comment l’option de connexion timeStampPrecision est exposée à ce chemin. Reproduisez les exemples de microsecondes et de millisecondes de l’issue et ajoutez ou mettez à jour une couverture ciblée si l’emplacement de test pertinent est identifié. C’est terminé lorsque le serveur reçoit la valeur d’epoch correcte pour chaque précision configurée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Type: bug

The FlightSQL JDBC driver always treats timestamps as milliseconds when sending them to the server, ignoring the connection setting timeStampPrecision (for example microseconds). As a result, when the connection precision is set to microseconds the driver truncates/offsets the timestamp and the value stored on the server is incorrect.

Expected behavior When the JDBC connection option timeStampPrecision is set (e.g. microseconds, milliseconds, nanoseconds), PreparedStatement#setTimestamp (and setTimestamp with timestamptz) should send timestamps with the configured precision so the server receives the correct epoch value.

Actual behavior The driver converts java.sql.Timestamp values to an epoch value assuming milliseconds. If the connection is configured for microseconds (or other precision) the conversion is incorrect and inserted timestamps are wrong.

String jdbcUrlFlight = "jdbc:arrow-flight-sql://localhost:9994?useEncryption=0";
try (Connection conn = DriverManager.getConnection(jdbcUrlFlight);
     PreparedStatement stmt = conn.prepareStatement("INSERT INTO ... VALUES (?, ?, ?, ?, ?)")) {

    for (RowData row : generatedData) {
        stmt.setDate(1, row.c_date());
        stmt.setTime(2, row.c_time());
        stmt.setTime(3, row.c_timetz());
        stmt.setTimestamp(4, row.c_timestamp());      // incorrect conversion happens here
        stmt.setTimestamp(5, row.c_timestamptz());   // and here
        stmt.addBatch();
    }
    stmt.executeBatch();
}

Example A — timestamp precision in microseconds (bug triggered)

  • Value I want to insert:

    • Timestamp object: "2024-11-03 12:45:09.869885001"
    • nanos = 869885001
    • fastTime = 1730634309000
  • DateTimeUtils#sqlTimestampToUnixTimestamp(Timestamp, TimeZone) returns: 1730637909869:

    • Interpreted as milliseconds, that is: 2024-11-03 12:45:09.869 (GMT)
  • Final value inserted into server: 1970-01-21 00:43:57.909869

    • Incorrect because the connection used microsecond precision but driver treated the value as milliseconds.

Example B — timestamp precision in milliseconds (works)

  • Value I want to insert:

    • "2023-11-29 09:47:32.659534860"
    • nanos = 659534860
    • fastTime = 1701247652000
  • Driver sends: 1701251252659 (interpreted as milliseconds)

  • Server receives: 2023-11-29 09:47:32.659 — correct when precision is milliseconds.

Environment

  • flight-sql-jdbc-driver-18.3.0.jar
  • Java: 17
  • Server FlightSQL implementation/version: 18.2
  • OS: Windows

Relevant code & suspected area

DateTimeUtils#sqlTimestampToUnixTimestamp(Timestamp, TimeZone) appears to be converting timestamps assuming millisecond precision.

public static long sqlTimestampToUnixTimestamp(Timestamp timestamp, TimeZone timeZone) {
        long time = timestamp.getTime();
        LocalDateTime dateTime = timestamp.toLocalDateTime();
        long unixTimestamp = dateTime.toEpochSecond(ZoneOffset.UTC) * 1000L + (long)dateTime.get(ChronoField.MILLI_OF_SECOND);
        if (timeZone != null) {
            unixTimestamp += (long)timeZone.getOffset(time);
        }

        unixTimestamp -= (long)DEFAULT_ZONE.getOffset(time);
        return unixTimestamp;
    }

The driver should respect the connection timeStampPrecision parameter, and correctlyreturn the exact epoch value (as a long) at the configured timestamp precision.

Langage dominant
Java
Étoiles
95
Forks
154
Merge moyen
2 j 10 h
PR mergées (30 j)
11

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/arrow-java

Toutes les issues de apache/arrow-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.