From dc2b52a023ead7d470353bbe97e1923326cafce6 Mon Sep 17 00:00:00 2001 From: Dan McDonald Date: Sat, 21 Feb 2026 16:16:34 -0500 Subject: [PATCH] IPD 14 - utime32_t as a possible bridge --- ipd/0014/README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/ipd/0014/README.md b/ipd/0014/README.md index f989998..197e9ae 100644 --- a/ipd/0014/README.md +++ b/ipd/0014/README.md @@ -43,6 +43,14 @@ Given that recompilation is required anyway, and we only support 64-bit hardware, it seems much easier to rebuild as 64-bit and be done with it. Such an approach would also address any other 32-bit limitations. +Recent releases of Oracle Solaris introduced the concept of `utime32_t`, +where, "unsigned values can be used to represent times from 1970-2106 +instead of the traditional signed 32-bit range of 1901-2038." This may +serve as a guardrail to prevent standard-coded or other hardcoded 32-bit +time-in-seconds fields. (Source: +[Alan Coopersmith](https://hachyderm.io/@alanc/116105750050187954) from +Fediverse site hachyderm.io.) + ## Other areas impacted It's possible that there may be areas beyond userland applications that @@ -59,6 +67,9 @@ are impacted. Such as: * illumos BPF has `struct bpf_timeval` which is an "on the wire" 32-bit `struct timeval`-alike. +The utime32_t may be able to mitigate impacts in these areas, at least until +the year 2106. + ## Implementation The basic plan is to simply rebuild all libraries and utilities as 64-bit.