[GH-2337] Fix the DateTimeParseException in GeoPackage reader

[jiayuasu]

Did you read the Contributor Guide?

• Yes, I have read the Contributor Rules and Contributor Development Guide

Is this PR related to a ticket?

• Yes, and the PR name follows the format [GH-2337] my subject. Closes Error Reading geopackage (DateTimeParseException) and Showing metadata #2337

What changes were proposed in this PR?

Problem: DateTimeParseException: Text '2023-12-31T12:00:00.000' could not be parsed at index 23

Root Cause: Instant.parse() requires timezone information, but GeoPackage datetime fields often don't include it

Solution: Enhanced the epoch() method with fallback parsing that treats datetime strings without timezone as UTC

Modified:

• spark/common/src/main/scala/org/apache/sedona/sql/datasources/geopackage/transform/DataTypesTransformations.scala
• Enhanced: The epoch() method to handle multiple datetime formats
• Added: Support for various millisecond formats (1, 2, 3 digits, or none)
• Maintained: Full backward compatibility with timezone-aware formats

How was this patch tested?

Added 1 more test case and a hand-made geopackage file that contains problematic datetime data

Did this PR include necessary documentation updates?

• No, this PR does not affect any public API so no need to change the documentation.

[Copilot]

Pull Request Overview

This PR fixes a DateTimeParseException in the GeoPackage reader when processing datetime fields that lack timezone information. The fix enhances the datetime parsing logic to handle multiple formats and treat timezone-less strings as UTC.

• Enhanced the epoch() method with fallback parsing for datetime strings without timezone
• Added support for various millisecond formats (1, 2, 3 digits, or none)
• Added comprehensive test coverage for the datetime parsing fix

Reviewed Changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 2 comments.

File	Description
DataTypesTransformations.scala	Enhanced epoch() method with fallback parsing and support for multiple datetime formats
GeoPackageReaderTest.scala (3 versions)	Added test case to verify datetime parsing without timezone information

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] Using early return in a for loop is not optimal for functional programming. Consider using datetimeFormatters.view.map(...) with find or collectFirst to make the code more functional and potentially more efficient.

Suggested change

	for (formatter <- datetimeFormatters) {
	try {
	val localDateTime = LocalDateTime.parse(timestampStr, formatter)
	return localDateTime.toInstant(ZoneOffset.UTC).toEpochMilli
	} catch {
	case _: DateTimeParseException =>
	// Continue to next formatter
	}
	}
	// If all formatters failed, throw a descriptive exception
	throw new IllegalArgumentException(
	s"Unable to parse datetime: $timestampStr. " +
	s"Expected formats: 'yyyy-MM-ddTHH:mm:ss[.S]' or 'yyyy-MM-ddTHH:mm:ss[.S]Z'")
	datetimeFormatters.view
	.map { formatter =>
	try {
	Some(LocalDateTime.parse(timestampStr, formatter).toInstant(ZoneOffset.UTC).toEpochMilli)
	} catch {
	case _: DateTimeParseException => None
	}
	}
	.collectFirst { case Some(epochMilli) => epochMilli }
	.getOrElse {
	// If all formatters failed, throw a descriptive exception
	throw new IllegalArgumentException(
	s"Unable to parse datetime: $timestampStr. " +
	s"Expected formats: 'yyyy-MM-ddTHH:mm:ss[.S]' or 'yyyy-MM-ddTHH:mm:ss[.S]Z'")
	}

[Copilot]

The error message format examples don't accurately reflect all supported patterns. It shows '[.S]' but the code supports .S, .SS, and .SSS formats. Consider updating to: 'yyyy-MM-ddTHH:mm:ss[.SSS|.SS|.S]' or 'yyyy-MM-ddTHH:mm:ss[.SSS|.SS|.S]Z'

Suggested change

	s"Expected formats: 'yyyy-MM-ddTHH:mm:ss[.S]' or 'yyyy-MM-ddTHH:mm:ss[.S]Z'")
	s"Expected formats: 'yyyy-MM-ddTHH:mm:ss[.SSS|.SS|.S]' or 'yyyy-MM-ddTHH:mm:ss[.SSS|.SS|.S]Z'")