build: Use language-agnostic (ISO 8601) timestamp format

[michaelo]

Summary

Instead of relying on non-portable, language-sensitive formats, use ISO 8601
extended datetime format as provided by date(1) for build output.
This format is fully language-agnostic, sortable and easy processable.

Identical has been done in:

• https://github.com/freebsd/vm-bhyve/pull/23
• https://github.com/freebsd/pkg/pull/2127

[michaelo]

Used the following search pattern: grep -r -e '$(date' -e '$( date' -e 'date' -e 'C date' --exclude '**/tests/**' --exclude '**/sys/contrib/**' --exclude '**/contrib/**' --exclude '**/tools/**' --exclude '**/crypto/**' . --color

No functional change to source code, samples etc. Just build.

Output now:

root@deblndw013x10v:~
# grep 2025- buildworld  kernel  installworld
buildworld:>>> World build started on 2025-08-30T23:29:44+02:00
buildworld:>>> World build completed on 2025-08-31T04:46:40+02:00
kernel:>>> Kernel build for GENERIC started on 2025-08-31T09:44:52+02:00
kernel:>>> Kernel build for GENERIC completed on 2025-08-31T10:15:28+02:00
kernel:>>> Install check kernel started on 2025-08-31T10:15:28+02:00
kernel:>>> Installing kernel GENERIC on 2025-08-31T10:15:28+02:00
kernel:>>> Installing kernel GENERIC completed on 2025-08-31T10:16:00+02:00
installworld:make[1]: /usr/obj/root/freebsd-src/amd64.amd64/toolchain-metadata.mk:1: Using cached toolchain metadata from build at deblndw013x10v.innomotics.net on 2025-08-30T23:37:30+02:00
installworld:>>> Install check world started on 2025-08-31T10:32:46+02:00
installworld:>>> Installing everything started on 2025-08-31T10:33:12+02:00
installworld:make[3]: /usr/obj/root/freebsd-src/amd64.amd64/toolchain-metadata.mk:1: Using cached toolchain metadata from build at deblndw013x10v.innomotics.net on 2025-08-30T23:37:30+02:00
installworld:>>> Installing everything completed on 2025-08-31T10:40:01+02:00
root@deblndw013x10v:~
# uname -a
FreeBSD deblndw013x10v.innomotics.net 15.0-PRERELEASE FreeBSD 15.0-PRERELEASE #0 use-iso-8601-n279977-b88a1ac3c533: 2025-08-31T10:14:57+02:00     [e-mail]:/usr/obj/root/freebsd-src/amd64.amd64/sys/GENERIC amd64

[michaelo]

Folks, any opinion on this? This is a readability and internationalization improvement.

[cperciva]

I like the idea, but this might break on cross-building from non-FreeBSD systems. @jrtc27 can you comment on this? I know you do such things.

[michaelo]

In D52303#1196812, @cperciva wrote:

I like the idea, but this might break on cross-building from non-FreeBSD systems. @jrtc27 can you comment on this? I know you do such things.

Interesting...I'd like to know how it could break it.

[cperciva]

In D52303#1196813, @michaelo wrote:

Interesting...I'd like to know how it could break it.

Well, date -I is not POSIX. So it might produce no output, or an odd error message instead.

[michaelo]

In D52303#1196819, @cperciva wrote:

In D52303#1196813, @michaelo wrote:

Interesting...I'd like to know how it could break it.

Well, date -I is not POSIX. So it might produce no output, or an odd error message instead.

Ah, I see. Although, I can't tell for macOS (which should have an up-to-date BSD date), GNU date works:

smartld@deblndw124v:~
$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.6 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.6 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.6"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.6"

smartld@deblndw124v:~
$ date -Iseconds
2025-09-06T21:06:00+02:00

The presence goes back to at least 2011: https://github.com/coreutils/coreutils/commit/2f1384b7e4674f2bdf4c471eee050bece59e01e6

[jrtc27]

It does appear both macOS and GNU date support -Iseconds. However, my concern with this change is that such timestamps are rather uglier and less human-readable, which is less of a problem for build system messages but more so for uname. I note that Linux uses LC_ALL=C date output for its uname, running uname -a on an Ubuntu system.

[michaelo]

In D52303#1196821, @jrtc27 wrote:

It does appear both macOS and GNU date support -Iseconds. However, my concern with this change is that such timestamps are rather uglier and less human-readable, which is less of a problem for build system messages but more so for uname. I note that Linux uses LC_ALL=C date output for its uname, running uname -a on an Ubuntu system.

I'd concur because all components are totally sorted. Moreover, the LC_ALL is redundant because the output is language-agnostic. That's the bonus.

[michaelo]

Example from Proxmox:

root@pve-1:~# uname -a
Linux pve-1.ppmd.siemens.net 6.14.8-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.14.8-2 (2025-07-22T10:04Z) x86_64 GNU/Linux

[michaelo]

In D52303#1196821, @jrtc27 wrote:

It does appear both macOS and GNU date support -Iseconds. However, my concern with this change is that such timestamps are rather uglier and less human-readable, which is less of a problem for build system messages but more so for uname. I note that Linux uses LC_ALL=C date output for its uname, running uname -a on an Ubuntu system.

Were you able to figure out something on your end?

[michaelo]

Rebase

@jrtc27 Have you checked what concerned you?

[jrtc27]

There was nothing for me to check. My concern was, and still is, how human-unfriendly the format is, instead of just fixing the locale.

[jrtc27]

I believe the right thing to do is just set LC_ALL=C in the places where it matters. Seconds since epoch is a horrible format to put in human-readable strings. Most of the existing uses of date already set LC_ALL=C, either explicitly for that command or implicitly from earlier in the script (such as both newvers.sh).

[imp]

sys/conf/newvers.sh

197 ↗

(On Diff #167494)

Why?

202 ↗

(On Diff #167494)

This changes a format that's been in use for 30 years without justification. While there's issues with it, the replacement is worse, imho.

[michaelo]

In D52303#1235058, @jrtc27 wrote:

I believe the right thing to do is just set LC_ALL=C in the places where it matters. Seconds since epoch is a horrible format to put in human-readable strings. Most of the existing uses of date already set LC_ALL=C, either explicitly for that command or implicitly from earlier in the script (such as both newvers.sh).

I think you totally misunderstand the command:

$ date -Iseconds
2025-12-04T09:10:07+01:00

I am not printing seconds since epoch!

[michaelo]

sys/conf/newvers.sh

197 ↗

(On Diff #167494)

For consistency with the rest? uname output?

202 ↗

(On Diff #167494)

There is one, the old Unix format follows no logic, it is a mess-endian throughout. ISO 8601 perfectlly sorts all members in big-endian. Otherwise I don't understand your objection.

[emaste]

sys/conf/newvers.sh

202 ↗

(On Diff #167494)

Changing what uname reports should probably be decoupled from build log format changes, and there's likely documentation or examples in the handbook that would also need to be changed. There might be scripts and tools that expect to parse uname output.

[michaelo]

sys/conf/newvers.sh

202 ↗

(On Diff #167494)

I can subscribe to that. Let me split it into two reviews.

[michaelo]

@emaste done as requested. It is only build now:

root@deblndw013x10v:~
# grep 2025- buildworld kernel installworld
buildworld:>>> World build started on 2025-12-05T13:46:35+01:00
buildworld:>>> World build completed on 2025-12-05T17:28:39+01:00
kernel:>>> Kernel build for GENERIC started on 2025-12-05T17:44:37+01:00
kernel:>>> Kernel build for GENERIC completed on 2025-12-05T18:14:43+01:00
kernel:>>> Install check kernel started on 2025-12-05T18:14:44+01:00
kernel:>>> Installing kernel GENERIC on 2025-12-05T18:14:44+01:00
kernel:>>> Installing kernel GENERIC completed on 2025-12-05T18:15:26+01:00
installworld:make[1]: /usr/obj/root/freebsd-src/amd64.amd64/toolchain-metadata.mk:1: Using cached toolchain metadata from build at deblndw013x10v.innomotics.net on 2025-12-05T13:52:04+01:00
installworld:>>> Install check world started on 2025-12-05T18:16:07+01:00
installworld:>>> Installing everything started on 2025-12-05T18:16:32+01:00
installworld:make[3]: /usr/obj/root/freebsd-src/amd64.amd64/toolchain-metadata.mk:1: Using cached toolchain metadata from build at deblndw013x10v.innomotics.net on 2025-12-05T13:52:04+01:00
installworld:>>> Installing everything completed on 2025-12-05T18:24:54+01:00
root@deblndw013x10v:~
# uname -a
FreeBSD deblndw013x10v.innomotics.net 16.0-CURRENT FreeBSD 16.0-CURRENT #1 use-iso-8601-build-n282325-56b9c752e8d6: Fri Dec  5 18:14:04 CET 2025     [e-mail]:/usr/obj/root/freebsd-src/amd64.amd64/sys/GENERIC amd64

I will raise a separate review for newvers.sh.

[jrtc27]

All these messages exist for humans to read, so why are we changing it to a less-human-readable format?

[michaelo]

In D52303#1235845, @jrtc27 wrote:

All these messages exist for humans to read, so why are we changing it to a less-human-readable format?

You consider a mess endian format easier to read with RFC timezones people need to look up? Can you enumarate all of them? Have you read my previous message? I am not printing seconds since epoch.

[jrtc27]

In D52303#1235848, @michaelo wrote:

In D52303#1235845, @jrtc27 wrote:

All these messages exist for humans to read, so why are we changing it to a less-human-readable format?

You consider a mess endian format easier to read with RFC timezones people need to look up? Can you enumarate all of them? Have you read my previous message? I am not printing seconds since epoch.

Yes, I read your message, I had forgotten some of the context when revisiting this. YYYY-MM-DDTHH:mm:ss+TZ is not human-friendly, it's a big mess of numbers that's way too information-dense.