FIX: replace strptime with fromisoformat for date parsing

[Lakshay Chauhan (nos1dot618)]

Work Item / Issue Reference

GitHub Issue: #784

---

Summary

Replace datetime.strptime() with the corresponding fromisoformat() APIs for date, datetime, and time parsing in Cursor. This removes the Ruff DTZ007 warnings caused by constructing naive datetimes with strptime() while preserving the existing parsing behavior. The existing cursor tests already cover date, datetime, and time parsing, so no new tests are required.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🟡 Changes recommended

Preserve previously supported input formats and add direct helper coverage.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Replaces strptime() with fromisoformat() APIs for cursor date, datetime, and time parsing.

Changes:

• Updates the three parsing helpers.
• Adds no direct regression tests.

File summaries

File	Findings
mssql_python/cursor.py	Moderate: New parsing rejects previously accepted non-zero-padded inputs; preserve compatibility and add regression coverage. Nit: Add direct tests for all three helpers, including prior valid and near-miss inputs.

Review details

Suppressed comments (2)

mssql_python/cursor.py:466

• datetime.fromisoformat() does not accept all inputs accepted by the removed format loop: strptime permits non-zero-padded fields, so values such as 2024-5-2 1:2:3 previously parsed but now return None. Please preserve those legacy inputs by normalizing the fields or using a compatibility fallback, and cover the case with a regression test.

            return datetime.datetime.fromisoformat(param)

mssql_python/cursor.py:481

• time.fromisoformat() is stricter than the previous strptime formats: %H, %M, and %S accepted non-zero-padded fields such as 1:2:3, whereas this implementation returns None. That is a compatibility regression; normalize the legacy form before calling fromisoformat() (or retain a fallback) and add a regression case.

            return datetime.time.fromisoformat(param)

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Lakshay Chauhan (nos1dot618)]

After some digging, I found that date.fromisoformat() is stricter than the previous strptime(..., "%Y-%m-%d") behavior. The previous implementation accepted dates with single-digit month/day components, such as 2024-5-2, whereas fromisoformat() rejects them and returns None.

Since this changes previously supported behavior and the goal is to maintain compatibility, I think it would be better to retain the existing functionality by normalizing the components before calling fromisoformat() (or retaining a compatibility fallback), along with a regression test for this case.