GUI: Use locale-aware GUIUtil::dateTimeStr for datetime fields

[kwsantiago]

Fixes #335

Startup time, Expiry time, and Last block time (in the Information tab and the sync overlay) were formatted with bare QDateTime::toString(). On Qt 5.15, which the release binaries are built against, that produces asctime-style ordering (Thu Jul 16 20:43:39 2026) with the time wedged between the day and the year, and it ignores the user's locale. Qt 6.7+ changed the default ordering, which is why this only shows up on Qt5 builds.

Switch these fields to GUIUtil::dateTimeStr, the same locale-aware formatting used for every other datetime in the GUI. Seconds are no longer shown, consistent with datetimes elsewhere.

Before / After

Before	After

[pdath]

I have negative feelings about this one.

The original format gave a date and time that made it obvious "when" it was, so you can ignore the country the machine was running in.
Now, depending on where you are in the world, it is no longer clear if we are looking at a month or a day first. Especially in the first 12 days of the month.

A user could "screenshot" a page and post it, but the date/time isn't clear unless you know where the user is posting from (or even when they are posting).

I would prefer to see something more like this (in most significant to least significant notation, and the month converted to text):
String customTime = GUIUtil::dateTimeStr(time_t_value, "yyyy-MMM-dd HH:mm:ss");
Which conveys the actual date and time, no matter where in the world you are, without any room for confusion.

I found 11 instances of this function across the codebase. Should there be a single utility function to format the date/time, with the formatting applied there, so that every date/time is always perfectly consistent?

Your thoughts?

[luke-jr]

Unfortunately, locales are a real thing. Displaying the datetime in the wrong locale doesn't seem like the right move IMO

[pdath]

ACK 68685bd
CONCEPT NAK 68685bd

ACK

I am giving this an ACK because I have reviewed the change and the migration from QDateTime::currentDateTime() to GUIUtil::dateTimeStr() is an improvement on the current solution and directly addresses issue #335. I have reviewed the code change and tested it to verify it works as expected.

CONCEPT NAK

I am giving it a concept NAK because I am opposed to the concept of localisation that provides a date/time that is ambiguous to a global audience, which Bitcoin has. For example, given the date "1/2/2022", it is not possible to know whether it refers to the first of February or the 2nd of January without knowing the origin of the person providing the information. I would prefer something based on ISO 8601, where date information is displayed from most to least significant. For example:

String customTime = GUIUtil::dateTimeStr(time_t_value, "yyyy-MM-dd HH:mm:ss");

This is globally consistent, works in every language and time zone, and is easily understood by users in every country. I would go so far as to say that basing a date/time on ISO 8601 is the Gold standard for a project with an international audience.

For example, BIP110 could activate on the 1st of September 2026. Users could post screenshots referencing both 1/9/2026 and 9/1/2026. Now, roll forward 10 years and consider a historian trying to piece this story together.

Review

I have reviewed the code change and tested it to verify it works as expected.

I also reviewed the change with CodeRabbit, and it found no issues.

I built the system using Ubuntu 24.04 running on ARMv8-A (64-bit) with gcc and used guix to create a Windows binary.

git clone https://github.com/bitcoinknots/bitcoin.git pr336
cd pr336
git fetch origin pull/336/head:pr336
git switch pr336

cmake -B build -DCMAKE_BUILD_TYPE=Release -DRDTS_CONSENT=IMPLICIT
nice cmake --build build -j$(nproc)

I then built using guix.

env HOSTS='x86_64-w64-mingw32' ./contrib/guix/guix-build

And tested with:

bitcoin-qt.exe -regtest

Everything worked as expected.