Re: POSIX.1-2024 requires 64-bit time_t

Collin Funk
2025-05-18T16:54:25Z

Hi Alejandro,

Alejandro Colomar <alx@kernel.org> writes:

> POSIX.1-2024 seems to require a 64-bit (or wider) time_t. I don't know
> how's the state of things as of now in glibc, so would you mind checking
> the time_t(3type) manual page and letting me know if anything needs to
> be updated or moved to history?
>
> At first glancce, I see
>
> DESCRIPTION
> time_t Used for time in seconds. According to POSIX,
> it is an integer type.
>
> where I'll have to append "of at least 64 bits". Then, there's
>
> NOTES
> On some architectures, the width of time_t can be
> controlled with the feature test macro _TIME_BITS.
> See feature_test_macros(7).
>
> Which sounds redundant with the new requirements. That sounds like it's
> for architectures that are non-conforming only, right? In the
> conforming ones, it wouldn't make sense. So, we'll need to clarify
> which architectures are conforming and which are not. Please let me
> know.

I documented this in glibc in commit
363bbdbd2aeaae1e00f3872f2ba19a4a3c17bdf1:

manual: Mention POSIX-1.2024 requires time_t to be 64 bit or wider.

* manual/time.texi (Time Types): Mention POSIX-1.2024 requires 64 bit
time_t.

Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

But as you mention and as documented in the manual, some older platforms
default to 32-bits unless _TIME_BITS is set to 64:

Currently the @code{time_t} type is 64 bits wide on all platforms
supported by @theglibc{}, except that it is 32 bits wide on a few
older platforms unless you define @code{_TIME_BITS} to 64.

I'll have to investigate the full list of architectures which that is
the case.

Collin