main: Use UTC in wallclock time log - #8193

I tested this locally and it prints like this:

Without strftime: 2026-05-12T09:34:52.3328526Z
With    strftime! 2026-05-12T09:34:52.332873Z

Ah sorry, I've just noticed you mentioned that in your PR. No strong opinion!

Less code is better - lets's just go without strftime

How about if we add Token::WallClockTz that prints jiff::Zoned::now()? Then we do not need to discuss what's "the right thing to do" and give users the necessary freedom

This would require us dealing with what to do when jiff cannot detect the timezone. I would prefer to keep this simple until we need more complexity.

Is this a hypothetical problem or can you reproduce a failure? When could this happen? If a system can't obtain the timezone, then a user simply should not configure {wallclock_local} into the log format? Am I missing something?

I don't have a strong opinion but I guess some people prefer local time with timezone information in their logs

I guess some people prefer local time with timezone information in their logs

I would not implement features we cannot remove without a breaking change to the CLI without a concrete need for it.

Is this a hypothetical problem or can you reproduce a failure? When could this happen? If a system can't obtain the timezone, then a user simply should not configure {wallclock_local} into the log format? Am I missing something?

It's a possible code path, so we should handle it without putting the burden on the user, which might not even be aware, that their system is configured in a way that breaks the timezone detection. Whether this is likely to happen and under which circumstances, I'm not sure.

This is what jiff's docs say:

If the system’s default time zone could not be determined, or if the tz-system crate feature is not enabled, then this returns TimeZone::unknown. A WARN level log will also be emitted with a message explaining why time zone detection failed. The fallback to an unknown time zone is a practical trade-off, is what most other systems tend to do and is also recommended by relevant standards such as freedesktop.org.

An unknown time zone behaves like TimeZone::UTC, but will print as Etc/Unknown when converting a Zoned to a string.

If you would like to fall back to UTC instead of the special “unknown” time zone, then you can do TimeZone::try_system().unwrap_or(TimeZone::UTC).

Falling back to UTC is most likely the better approach as I don't think we want an IANA-style identifier in the logs as that would create a lot of noise.

If Token::WallClockTz is not required to land this PR, I would prefer to keep it separate.

Sure! We can add it in future if needed - no need to slow down this PR

While on it, do you think it would make sense to add documentation to Token::WallClock saying:

Wallclock using ISO 8601 / RFC 3339-style.?

WDYT? We missed this in the original PR

Unit test is failing:

thread 'logger::tests::logger_wallclock_is_rfc3339' panicked at cloud-hypervisor/src/logger.rs:370:9:
assertion `left == right` failed: got: 2026-05-12T15:59:00.66858127Z
  left: 29
 right: 30
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    logger::tests::logger_wallclock_is_rfc3339

test result: FAILED. 34 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `-p cloud-hypervisor --bin cloud-hypervisor`

I wasn't aware that jiff uses the minimum required precision to render the value. I fixed the precision to match the behavior from before.