Phase 0a: Migrate Joda-Time to java.time.Instant#165
Phase 0a: Migrate Joda-Time to java.time.Instant#165devin-ai-integration[bot] wants to merge 2 commits into
Conversation
Replace all org.joda.time.DateTime usages with java.time.Instant across domain entities, DTOs, query services, MyBatis type handler, Jackson serializer, GraphQL datafetchers, and tests. Remove joda-time dependency from build.gradle.
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…ions Addresses review feedback: SQLite stores timestamps as text, so the JDBC driver needs an explicit UTC Calendar to correctly format/parse them regardless of the JVM's default timezone.
| @MappedTypes(Instant.class) | ||
| public class DateTimeHandler implements TypeHandler<Instant> { | ||
|
|
||
| private static final Calendar UTC_CALENDAR = Calendar.getInstance(TimeZone.getTimeZone("UTC")); |
There was a problem hiding this comment.
🚩 Shared mutable Calendar instance in DateTimeHandler is not thread-safe
The UTC_CALENDAR at DateTimeHandler.java:18 is a static final Calendar shared across all threads. Calendar is mutable and not thread-safe. JDBC's getTimestamp(col, Calendar) and setTimestamp(i, ts, Calendar) may internally modify the Calendar's fields during timezone conversion. Under concurrent database access, this could theoretically lead to corrupted timestamp reads/writes. This is a pre-existing issue (unchanged by the PR), but since the PR touched every method in this class, it's worth noting. A safer approach would be to create a new Calendar per call or use TimeZone.getTimeZone("UTC") directly.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it. |
1 participant
Summary
Replaces all
org.joda.time.DateTimeusage withjava.time.Instantas a prerequisite for the Java 11→21 / Spring Boot 2→3 migration. This eliminates the externaljoda-time:joda-time:2.10.13dependency entirely.Key changes:
Article,Comment):DateTimefields →Instant;new DateTime()→Instant.now()ArticleData,CommentData): same field type migrationDateTimeCursor: extendsPageCursor<Instant>, usesInstant.ofEpochMilli/toEpochMilliDateTimeHandler(MyBatis):@MappedTypes(Instant.class), converts viaTimestamp.from(instant)/timestamp.toInstant()JacksonCustomizations: custom serializer now targetsInstant.class, formats withDateTimeFormatter.ISO_INSTANTISODateTimeFormat.dateTime().withZoneUTC().print(...)withinstant.toString()(produces ISO-8601)CursorPageParameter<DateTime>→CursorPageParameter<Instant>new DateTime()→Instant.now(),new DateTime().minusHours(1)→Instant.now().minusMillis(3600000)build.gradle: removedimplementation 'joda-time:joda-time:2.10.13'All tests pass with
./gradlew clean test -x jacocoTestCoverageVerification.Link to Devin session: https://partner-workshops.devinenterprise.com/sessions/092562f72c11450cb899dab49bfffe94
Requested by: @mbatchelor81