fix: preserve datetime strings in SQLite to maintain original formatting

[modelorona]

Fixes #309

Summary

SQLite stores DATETIME columns as TEXT, allowing flexible datetime formats. The previous behavior was parsing and reformatting datetime strings to ISO 8601, which broke applications depending on specific datetime formats.

This change:

• Overrides ConvertStringValue to preserve datetime strings as-is for DATE, DATETIME, and TIMESTAMP columns
• Delegates to the base GORM implementation for other data types
• Ensures both insert and update operations preserve the original datetime format

Test Plan

• Create a SQLite table with DATETIME column
• Insert data with custom datetime format (e.g., 2024-08-22 22:15:07.739390)
• Verify the data is displayed in the original format
• Update the data with a different custom format
• Verify the update succeeds and preserves the new format

Generated with Claude Code

[jazzberry-ai]

Bug Report

Name	Severity	Example test case	Description
Invalid datetime strings are preserved in DATETIME columns	Medium	Create a table with a DATETIME column. Insert a row with the value "not a date" into the DATETIME column. The value will be stored as is, without validation.	The SQLite3 plugin preserves the original string value for DATE, DATETIME, and TIMESTAMP columns without validating that the string is a valid datetime. This can lead to invalid data being stored in the database and potential errors or unexpected behavior when querying or using the data.

_{Comments? Email us.}

[modelorona]

@claude can you make sure the frontend viewing of the date works as well with these flexible SQLite types? it must display it as a string in the worst case scenario and then send it to the backend exactly as it received it.

[claude]

Claude finished @modelorona's task —— View job

---

Frontend Date Handling Analysis

I've analyzed the frontend code and have good news: the frontend already handles flexible SQLite datetime types correctly!

Todo List:

• Gather context on the PR changes
• Search for frontend date display components
• Review how dates are received from the backend
• Check how dates are sent back to the backend
• Analyze potential issues with flexible datetime formats
• Provide recommendations

Key Findings:

1. Date Display (frontend/src/components/table.tsx:281)

• Dates are displayed as raw strings without any formatting
• The value is rendered directly: {editedData}
• No date parsing or formatting libraries are used

2. Date Editing

• Users edit dates as plain text in a code editor
• No date pickers or validation are applied
• The edited value is preserved exactly as entered

3. Backend Communication (frontend/src/pages/storage-unit/explore-storage-unit.tsx:157-190)

• All values (including dates) are sent as strings via GraphQL
• The RecordInput type defines Value: String (frontend/src/generated/graphql.tsx:240)
• Values are passed through without transformation

4. Current Behavior

The frontend already:

• ✅ Displays dates as strings (exactly as received from backend)
• ✅ Sends dates back to backend exactly as received/edited
• ✅ Handles "invalid" dates gracefully (they're just strings)

Potential Considerations:

1. User Experience: While the current implementation works correctly with flexible datetime formats, users see raw database values like 2024-08-22 22:15:07.739390. This is functional but may not be the most user-friendly.

2. Validation: As noted by Jazzberry AI, invalid datetime strings (e.g., "not a date") will be accepted and stored. This is consistent with SQLite's flexible TEXT storage but may lead to data quality issues.

3. Sorting: Table sorting will be alphabetical rather than chronological, which might not produce expected results for dates in different formats.

Recommendation:

The frontend implementation is already compatible with the SQLite datetime preservation changes in this PR. No frontend changes are required to support flexible datetime formats - the system will work as intended, displaying and preserving datetime strings exactly as stored in the database.