FINERACT-2719: Add submittedOnDateTime to journal entry responses

[Samer-Melhem-FOO]

Description

The Journal Entries API only returns submittedOnDate (date-only), so any UI reading it always shows a time of 00:00:00, even though the journal entry's actual creation timestamp is stored in acc_gl_journal_entry.created_on_utc.

This adds a new optional submittedOnDateTime field to JournalEntryData (Fineract-style [year, month, day, hour, minute, second] array), sourced from created_on_utc in JournalEntryReadPlatformServiceImpl. submittedOnDate is left unchanged for backward compatibility.

JIRA: https://issues.apache.org/jira/browse/FINERACT-2719

Checklist

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance.
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.

Note: no existing unit/integration test covers JournalEntryReadPlatformServiceImpl's row-mapping logic (it's a plain JDBC RowMapper, not easily unit-testable in isolation), so none were added — happy to add integration-test coverage if a reviewer points to the right harness for it.

[adamsaghy]

I see no benefit of adding this field. If you want to have a sorted list, feel free to sort by created date time / and return that...

[Samer-Melhem-FOO]

I see no benefit of adding this field. If you want to have a sorted list, feel free to sort by created date time / and return that...

The benefit isn't sorting — it's the displayed value itself. submittedOnDate is date-only, so any UI that reads it always renders a time of 00:00:00, even though the actual creation timestamp exists in acc_gl_journal_entry.created_on_utc. Without submittedOnDateTime, there's no way for a client to show when a journal entry was actually created, only what day.

submittedOnDate is left untouched for backward compatibility, so existing consumers (including anything sorting by it) are unaffected — this is purely additive for clients that want the real timestamp.

[adamsaghy]

I see no benefit of adding this field. If you want to have a sorted list, feel free to sort by created date time / and return that...

The benefit isn't sorting — it's the displayed value itself. submittedOnDate is date-only, so any UI that reads it always renders a time of 00:00:00, even though the actual creation timestamp exists in acc_gl_journal_entry.created_on_utc. Without submittedOnDateTime, there's no way for a client to show when a journal entry was actually created, only what day.

submittedOnDate is left untouched for backward compatibility, so existing consumers (including anything sorting by it) are unaffected — this is purely additive for clients that want the real timestamp.

Disclose the created date and time, but there’s no need to introduce a new field when one already exists with the necessary data.