WiredTiger API accepts timestamps as hexadecimal strings without "0x", but reports back timestamps as decimals in errors or verbose messages. This causes confusion at times.

Imagine the application trying to set the stable timestamp to 184791, but failing with the following error:

[1629230866:327816][11618:0x7f8980ff9700], WT_CONNECTION.set_timestamp: __wt_txn_global_set_timestamp, 431: set_timestamp: oldest timestamp (0, 1591186) must not be later than stable timestamp (0, 1591185): Invalid argument test_timestamp_abort: FAILED: thread_ts_run/178: td->conn->set_timestamp(td->conn, tscfg): Invalid argument

Since 0x184791 = 1591185, so it makes sense to fail the call if stable is being set behind the oldest. But it is easy to forget that the API takes hexadecimals and the error returned is decimal. Ideally there should be a consistency.

This was reported in WT-7968, and end-users sometimes get caught by this issue. I commented in that ticket:

The error message was confusing, since we set timestamps in hex and report them back in decimal. There is a long history of how we reached here: We started with a variable length timestamp, so the application can chose to build WiredTiger with however long timestamps they need. The API found it easier to provide timestamps in hex format - and our API only accepts strings as "configuration". Eventually we moved to 64-bits timestamps only with hex input. We used to print timestamps in an inconsistent way, until we decided to print how MongoDB expects timestamps to be - decimals. It is confusing, but a by product of how we reached here. I will open a ticket to encourage a discussion around improving things, if we can. reported in this ticket

I hope we can find ways to mitigate this issue through this ticket.