MBA-72: Migrate from Joda Time to java.time API

[devin-ai-integration]

Summary

Replaces all Joda Time (org.joda.time.DateTime) usage with java.time.Instant across the entire codebase and removes the joda-time:2.10.13 dependency.

Changes span 17 files across 4 layers:

• Domain entities (Article, Comment): DateTime fields → Instant
• DTOs (ArticleData, CommentData): same field type change
• Infrastructure (DateTimeHandler): MyBatis TypeHandler rewritten for Instant ↔ Timestamp conversion using Timestamp.from() / toInstant()
• Serialization: Jackson custom serializer and GraphQL datafetchers now use DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'").withZone(ZoneOffset.UTC) instead of Joda's ISODateTimeFormat
• Pagination (DateTimeCursor): uses toEpochMilli() / Instant.ofEpochMilli() instead of Joda equivalents
• Tests: all 4 test files updated to use Instant.now() and java.time formatters

Review & Testing Checklist for Human

• Date format output parity: Verify that the java.time formatter yyyy-MM-dd'T'HH:mm:ss.SSS'Z' produces output identical to Joda's ISODateTimeFormat.dateTime().withZoneUTC(), especially at boundary values (e.g. zero millis, midnight). Both should produce 2024-01-01T00:00:00.000Z but edge cases around sub-millisecond precision may differ.
• MyBatis DateTimeHandler round-trip: Confirm that Timestamp.from(instant) and timestamp.toInstant() preserve the same precision as the prior new Timestamp(dateTime.getMillis()) / new DateTime(timestamp.getTime()) path, particularly with your production database (the test suite uses SQLite).
• No residual Joda transitive dependency: Confirm no other library in the dependency tree still pulls in or requires Joda Time at runtime.
• GraphQL datafetchers create DateTimeFormatter inline on every call rather than using a static final constant (unlike JacksonCustomizations which does extract it). Not a correctness issue, but worth deciding if you want consistency.

Recommended test plan: Start the application locally, create an article via POST /articles, and verify the createdAt/updatedAt fields in the JSON response match the expected ISO-8601 format. Also verify cursor-based pagination (/articles?cursor=...) still works correctly.

Notes

• Instant.now().minusSeconds(3600) replaces new DateTime().minusHours(1) in tests — semantically equivalent.
• All existing tests pass. Spotless formatting applied.

Link to Devin session: https://app.devin.ai/sessions/c260e1d5a9ba4fee99beb1cd4cbb818a
Requested by: @shayanshafii

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🟡 updateUser does not persist token to localStorage, breaking consistency with login/register

In useAuth.ts, both login (line 48) and register (line 54) save the returned token to localStorage.setItem('token', userData.token) before calling setUser. However, updateUser at line 63-66 only calls setUser(updatedUser) without saving the token. This means the token in localStorage and the token in React state can diverge. While the current backend (CurrentUserApi.java:48) echoes back the same token, if the response token ever differs (e.g., token rotation, claims update), all subsequent API calls would use the stale localStorage token via the axios interceptor (api.ts:24), causing authentication failures.

Suggested change

	const updateUser = async (userData: Partial<UserWithToken>) => {
	const updatedUser = await authApi.updateUser(userData);
	setUser(updatedUser);
	};
	const updateUser = async (userData: Partial<UserWithToken>) => {
	const updatedUser = await authApi.updateUser(userData);
	localStorage.setItem('token', updatedUser.token);
	setUser(updatedUser);
	};

---

Was this helpful? React with 👍 or 👎 to provide feedback.