payjoin-cli history: display human-readable timestamp instead of raw unix seconds

[codaMW]

Which crate is this feature request for?

No response

Please describe the feature you'd like to see added.

The history command displays session completion times as raw unix
seconds. In payjoin-cli/src/app/v2/mod.rs line 130 there is an
existing TODO comment confirming this is unfinished:

match self.completed_at {
    None => "Not Completed".to_string(),
    Some(secs) => {
        // TODO: human readable time
        secs.to_string()
    }
}

A completed session would display like:
abc123 Sender 1744123456 Session success

instead of something readable like:
abc123 Sender 2026-04-08 14:32:01 UTC Session success

Is your feature related to a problem, if so please describe it.

In payjoin-cli/src/app/v2/mod.rs line 130, there is an existing
TODO comment acknowledging this:

// TODO: human readable time
secs.to_string()

Raw unix timestamps are unreadable to operators monitoring session history.

Describe the solution you'd like

Format the unix timestamp into a readable UTC datetime string.
Question: should this use an existing crate like humantime or chrono,
or is a std-only solution preferred to avoid new dependencies?

Describe any alternatives you've considered

No response

Please leave any additional context

No response

[Mshehu5]

Thanks for spotting this and opening an issue.

One approach I used in my bdk-cli PR was formatting the date directly in SQLite similar to what you suggested. You can see the implementation here:

bitcoindevkit/bdk-cli@ebf2b71#diff-cb4ce92208403b81aa83dff9a08c55d917bbf75a08f745a564cd9018a55ad502R196-R199

[codaMW]

Thanks for picking this up so quickly @zealsham. I filed this issue after finding the TODO in the codebase. Happy to review, the SQLite datetime approach suggested by @Mshehu5 is clean. One note: the patch coverage is at 0% per Coveralls , would a unit test asserting the formatted output for a known timestamp be feasible here?

[zealsham]

Raw unix timestamps are unreadable to operators monitoring session history.

operators can not monitor session history, the session history lives on the local device of the sender or receiver. I think my solution is sufficient for the case of receiver/senders seeing their session history.