build/newvers: Use language-agnostic (ISO 8601) timestamp format during build and newvers

[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 and newvers.sh.
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?