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

bulkcopy() silently truncates fractional seconds in string datetime values to microseconds

Fermée
  • Quelque chose ne va pas ?
#869 2 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

@jahnvi480 y travaille déjà.

Depuis le 28/10/2026.

  • #774 par @jahnvi480 — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python, rust, sql
Domaine
database, databases

Piste de recherche

Start by tracing how Cursor.bulkcopy() parses string values into DATETIME2 and DATETIMEOFFSET, then compare that path with execute()/executemany() and the Arrow timestamp path. Reproduce with the supplied seven-digit fractional value and trailing-Z example, checking behavior on Python 3.10 and 3.11. Done means bulkcopy preserves all seven digits like executemany and accepts server-valid input, or rejects precision loss explicitly.

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

Description

area: bulk-copy bug inADO triage done under development
Summary

When a string is bound to a DATETIME2 column through Cursor.bulkcopy(), the Rust core parses it with Python's datetime.fromisoformat before sending it. datetime only holds microseconds, so a seven-digit fraction is truncated to six with no warning. The same string through execute()/executemany() is sent to the server as text and SQL Server stores all seven digits.

On Python 3.10 the same parser also rejects a trailing Z, which the server accepts. From 3.11 that case works. This is probably fine since python 3.10 is EOL in a few days, but I wanted to raise since your docs explicitly say you need >=3.10 for bulkcopy.

To reproduce
import uuid
import mssql_python

conn = mssql_python.connect(CONN_STR, autocommit=True)
cur = conn.cursor()
table = f"dbo.Repro_{uuid.uuid4().hex[:8]}"
cur.execute(f"CREATE TABLE {table} (lbl VARCHAR(20), dt DATETIME2)")

value = "2024-07-01 12:00:00.1234567"

cur.executemany(f"INSERT INTO {table} VALUES (?, ?)", [("executemany", value)])
cur.bulkcopy(table, [("bulkcopy", value)])

cur.execute(f"SELECT lbl, CONVERT(varchar(27), dt, 121) FROM {table}")
print(cur.fetchall())
cur.execute(f"DROP TABLE {table}")

Observed:

Python 3.11:

[('executemany', '2024-07-01 12:00:00.1234567'),
 ('bulkcopy',    '2024-07-01 12:00:00.1234560')]

Python 3.10, where fromisoformat also rejects Z:

cur.bulkcopy(table, [("bulkcopy", "2024-07-01T12:00:00Z")])
ValueError: Invalid datetime format '2024-07-01T12:00:00Z'. Expected ISO format like
'2024-01-15 09:30:00' or '2024-01-15T09:30:00': ValueError: Invalid isoformat string: ...

Note:

bulkcopy_arrow() with a timestamp[ns] column stores all seven digits, into both DATETIME2 and DATETIMEOFFSET:

import pyarrow as pa
ns = pa.array([1719835200_123456700], pa.timestamp("ns"))   # 2024-07-01 12:00:00.1234567
cur.bulkcopy_arrow(table, pa.table({"lbl": ["arrow"], "dt": ns}))
# -> '2024-07-01 12:00:00.1234567'
Expected behavior

bulkcopy() stores the same value as executemany() for the same input string. In particular, a DATETIME2(7) column receives all seven digits, and inputs that SQL Server accepts are not rejected on the client.

Suggested fixes, in order of preference
  1. Parse ISO 8601 strings in Rust directly into the TDS DATETIME2/DATETIMEOFFSET representation, which has 100 ns resolution, the same way the Arrow path already consumes nanosecond buffers. This also removes the dependence on the running interpreter's fromisoformat behaviour.
  2. Alternatively, send string values for datetime columns to the server as text and let it convert, matching the execute path.
  3. At minimum, raise when a fraction has more digits than can be represented instead of truncating. Silent data loss is the worst of the three outcomes.
Langage dominant
Python
Étoiles
481
Forks
62
Merge moyen
2 j 11 h
PR mergées (30 j)
12

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

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 microsoft/mssql-python

Toutes les issues de microsoft/mssql-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

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