Remove unused datetime_from_timestamp import and add integration test

- Removed unused import of datetime_from_timestamp from deserializers.pyx
  (datetime_from_timestamp is still used in util.py by UUID and Date utilities)
- Added integration test for large timestamp precision in test_types.py
  that verifies round-trip identity for timestamps far from epoch (year 2300, 1640, 2500)

Co-authored-by: Lorak-mmk <5958117+Lorak-mmk@users.noreply.github.com>

Author: Copilot

cassandra/deserializers.pyx

@@ -17,7 +17,7 @@ from libc.stdint cimport int32_t, uint16_t, int64_t
 
 include 'cython_marshal.pyx'
 from cassandra.buffer cimport Buffer, to_bytes, slice_buffer
-from cassandra.cython_utils cimport datetime_from_timestamp, datetime_from_timestamp_ms
+from cassandra.cython_utils cimport datetime_from_timestamp_ms
 
 from cython.view cimport array as cython_array
 from cassandra.tuple cimport tuple_new, tuple_set

tests/integration/standard/test_types.py

@@ -429,6 +429,55 @@ def test_timezone_aware_datetimes_are_timestamps(self):
         result = s.execute("SELECT b FROM tz_aware WHERE a='key2'").one().b
         assert dt.utctimetuple() == result.utctimetuple()
 
+    def test_large_timestamp_precision(self):
+        """
+        Test that large timestamp values (far from epoch) maintain precision
+        through round-trip serialization/deserialization.
+        
+        Verifies the fix for precision loss issue where timestamps more than
+        ~300 years from Unix epoch would lose millisecond precision due to
+        floating-point conversion.
+        
+        @jira_ticket PYTHON-XXXXX
+        @expected_result Timestamps far from epoch should round-trip with exact precision
+        """
+        s = self.session
+        s.execute("CREATE TABLE large_timestamps (pk timestamp PRIMARY KEY)")
+        
+        # Test timestamps far from epoch (year 2300 and year 1640)
+        # These would lose precision with float conversion
+        test_timestamps = [
+            datetime(2300, 1, 1, 0, 0, 0, 1000),   # 1 millisecond in year 2300
+            datetime(2300, 1, 1, 0, 0, 0, 999000),  # 999 milliseconds in year 2300
+            datetime(1640, 1, 1, 0, 0, 0, 1000),   # 1 millisecond in year 1640
+            datetime(2500, 12, 31, 23, 59, 59, 999000),  # Very far future
+        ]
+        
+        for original_timestamp in test_timestamps:
+            with self.subTest(timestamp=original_timestamp):
+                # Insert using prepared statement (uses serialization)
+                insert = s.prepare("INSERT INTO large_timestamps (pk) VALUES (?)")
+                s.execute(insert, [original_timestamp])
+                
+                # Retrieve the timestamp (uses deserialization)
+                result = s.execute("SELECT pk FROM large_timestamps WHERE pk = ?", [original_timestamp]).one()
+                assert result is not None, f"Failed to retrieve timestamp {original_timestamp}"
+                retrieved_timestamp = result.pk
+                
+                # Verify exact equality - microseconds should match
+                assert retrieved_timestamp == original_timestamp, \
+                    f"Timestamp mismatch: original={original_timestamp}, retrieved={retrieved_timestamp}"
+                
+                # Verify we can query using the retrieved timestamp (round-trip test)
+                result2 = s.execute("SELECT pk FROM large_timestamps WHERE pk = ?", [retrieved_timestamp]).one()
+                assert result2 is not None, \
+                    f"Failed to query with retrieved timestamp {retrieved_timestamp}"
+                assert result2.pk == original_timestamp, \
+                    f"Second round-trip failed: expected={original_timestamp}, got={result2.pk}"
+                
+                # Clean up for next test
+                s.execute("DELETE FROM large_timestamps WHERE pk = ?", [original_timestamp])
+
     def test_can_insert_tuples(self):
         """
         Basic test of tuple functionality