POSIX.1-2024 requires 64-bit time_t

POSIX.1-2024 requires 64-bit time_t

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

Hi!

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.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Collin Funk]

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

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

[Mark Harris]

On Sun, May 18, 2025 at 9:54 AM Collin Funk <collin.funk1@gmail.com> wrote:
>
> 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
>

For glibc, all 64-bit platforms, and the most recently added 32-bit
platforms (arc, riscv32, or1k), use 64-bit time_t.  All older but
still-supported 32-bit platforms (arm, csky, hppa, m68k, microblaze,
mips, powerpc, s390, sh, sparc, x86) currently use 32-bit time_t by
default but can use 64-bit time_t with -D_TIME_BITS=64.  For musl, all
platforms use 64-bit time_t.

POSIX.1-2024 requires that an implementation offer a conforming
environment that supports 64-bit time_t, but it is also free to offer
other non-conforming environments that use 32-bit time_t.

 - Mark

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

Hi Mark,

On Sun, May 18, 2025 at 02:52:30PM -0700, Mark Harris wrote:
> For glibc, all 64-bit platforms, and the most recently added 32-bit
> platforms (arc, riscv32, or1k), use 64-bit time_t.  All older but
> still-supported 32-bit platforms (arm, csky, hppa, m68k, microblaze,
> mips, powerpc, s390, sh, sparc, x86) currently use 32-bit time_t by
> default but can use 64-bit time_t with -D_TIME_BITS=64.  For musl, all
> platforms use 64-bit time_t.

Thanks!

> POSIX.1-2024 requires that an implementation offer a conforming
> environment that supports 64-bit time_t, but it is also free to offer
> other non-conforming environments that use 32-bit time_t.

Are you sure?  That's not what I read from the standard.

POSIX.1-2024 says something like that for other types; for example:

	The implementation shall support one or more programming
	environments in which the widths of blksize_t, pid_t, size_t,
	ssize_t, and suseconds_t are no greater than the width of type
	long.

But for time_t it is very strict:

	time_t shall be an integer type with a width (see <stdint.h>) of
	at least 64 bits.

It doesn't seem to support such alternate environments for time_t.  Of
course, an implementation is free to not conform, but then it's a non-
conforming implementation.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mark Harris]

On Sun, May 18, 2025 at 3:06 PM Alejandro Colomar <alx@kernel.org> wrote:
>
> Hi Mark,
>
> On Sun, May 18, 2025 at 02:52:30PM -0700, Mark Harris wrote:
> > For glibc, all 64-bit platforms, and the most recently added 32-bit
> > platforms (arc, riscv32, or1k), use 64-bit time_t.  All older but
> > still-supported 32-bit platforms (arm, csky, hppa, m68k, microblaze,
> > mips, powerpc, s390, sh, sparc, x86) currently use 32-bit time_t by
> > default but can use 64-bit time_t with -D_TIME_BITS=64.  For musl, all
> > platforms use 64-bit time_t.
>
> Thanks!
>
> > POSIX.1-2024 requires that an implementation offer a conforming
> > environment that supports 64-bit time_t, but it is also free to offer
> > other non-conforming environments that use 32-bit time_t.
>
> Are you sure?  That's not what I read from the standard.
>
> POSIX.1-2024 says something like that for other types; for example:
>
>         The implementation shall support one or more programming
>         environments in which the widths of blksize_t, pid_t, size_t,
>         ssize_t, and suseconds_t are no greater than the width of type
>         long.
>
> But for time_t it is very strict:
>
>         time_t shall be an integer type with a width (see <stdint.h>) of
>         at least 64 bits.
>
> It doesn't seem to support such alternate environments for time_t.  Of
> course, an implementation is free to not conform, but then it's a non-
> conforming implementation.
>
>
> Have a lovely night!
> Alex
>
> --
> <https://www.alejandro-colomar.es/>

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/unistd.h.html

"Implementations may support multiple programming environments with
some of them conforming to this standard and some not conforming. The
_POSIX_Vn_ILP* and _POSIX_Vn_LP* constants, and corresponding
sysconf() and getconf calls, only indicate whether each programming
environment is supported; they do not indicate anything about
conformance of the environments that are supported. For example, an
implementation may support the ILP32_OFF32 environment for legacy
reasons with a 32-bit time_t, whereas in a conforming environment
time_t is required to have a width of at least 64 bits. Application
writers should consult an implementation's POSIX Conformance Document
for information about the conformance of each supported programming
environment."

 - Mark

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

On Sun, May 18, 2025 at 03:09:07PM -0700, Mark Harris wrote:
> On Sun, May 18, 2025 at 3:06 PM Alejandro Colomar <alx@kernel.org> wrote:
> >
> > Hi Mark,
> >
> > On Sun, May 18, 2025 at 02:52:30PM -0700, Mark Harris wrote:
> > > For glibc, all 64-bit platforms, and the most recently added 32-bit
> > > platforms (arc, riscv32, or1k), use 64-bit time_t.  All older but
> > > still-supported 32-bit platforms (arm, csky, hppa, m68k, microblaze,
> > > mips, powerpc, s390, sh, sparc, x86) currently use 32-bit time_t by
> > > default but can use 64-bit time_t with -D_TIME_BITS=64.  For musl, all
> > > platforms use 64-bit time_t.
> >
> > Thanks!
> >
> > > POSIX.1-2024 requires that an implementation offer a conforming
> > > environment that supports 64-bit time_t, but it is also free to offer
> > > other non-conforming environments that use 32-bit time_t.
> >
> > Are you sure?  That's not what I read from the standard.
> >
> > POSIX.1-2024 says something like that for other types; for example:
> >
> >         The implementation shall support one or more programming
> >         environments in which the widths of blksize_t, pid_t, size_t,
> >         ssize_t, and suseconds_t are no greater than the width of type
> >         long.
> >
> > But for time_t it is very strict:
> >
> >         time_t shall be an integer type with a width (see <stdint.h>) of
> >         at least 64 bits.
> >
> > It doesn't seem to support such alternate environments for time_t.  Of
> > course, an implementation is free to not conform, but then it's a non-
> > conforming implementation.
> >
> >
> > Have a lovely night!
> > Alex
> >
> > --
> > <https://www.alejandro-colomar.es/>
> 
> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/unistd.h.html
> 
> "Implementations may support multiple programming environments with
> some of them conforming to this standard and some not conforming. The
> _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants, and corresponding
> sysconf() and getconf calls, only indicate whether each programming
> environment is supported; they do not indicate anything about
> conformance of the environments that are supported. For example, an
> implementation may support the ILP32_OFF32 environment for legacy
> reasons with a 32-bit time_t, whereas in a conforming environment
> time_t is required to have a width of at least 64 bits. Application
> writers should consult an implementation's POSIX Conformance Document
> for information about the conformance of each supported programming
> environment."

Thanks!  Makes sense.


Cheers,
Alex

> 
>  - Mark

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Collin Funk]

Mark Harris <mark.hsj@gmail.com> writes:

> For glibc, all 64-bit platforms, and the most recently added 32-bit
> platforms (arc, riscv32, or1k), use 64-bit time_t.  All older but
> still-supported 32-bit platforms (arm, csky, hppa, m68k, microblaze,
> mips, powerpc, s390, sh, sparc, x86) currently use 32-bit time_t by
> default but can use 64-bit time_t with -D_TIME_BITS=64.  For musl, all
> platforms use 64-bit time_t.

Thanks for the details.

I had looked into it and it seemed that time_t was 32-bits where
__WORD_SIZE == 32.  But it seems I missed the newer 32-bit platforms.

Collin

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

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

> 
> For glibc, all 64-bit platforms, and the most recently added 32-bit
> platforms (arc, riscv32, or1k), use 64-bit time_t.  All older but
> still-supported 32-bit platforms (arm, csky, hppa, m68k, microblaze,
> mips, powerpc, s390, sh, sparc, x86) currently use 32-bit time_t by
> default but can use 64-bit time_t with -D_TIME_BITS=64.  For musl, all
> platforms use 64-bit time_t.
> 

Yes.

Gentoo is one of the few places where this is still relevant, and where
the upgrade path is also tricky (since we're a source distribution).

We are still in the preparation phase of moving all 32bit architectures
to 64-bit time_t, but nearly all pieces are in place now.

We intend to change the ABI part of CHOST, from -gnu to -gnut64, to
clarify that this can subtly break sytemwide binary compatibility.

[Not of glibc itself, but of other libraries that include time_t in
their headers somehow.]
[[This is not an academic issue. It broke certificate validation of
openssl.]]

For more details (offtopic in this context) please contact me or Sam.

> POSIX.1-2024 requires that an implementation offer a conforming
> environment that supports 64-bit time_t, but it is also free to offer
> other non-conforming environments that use 32-bit time_t.
> 
>  - Mark
> 


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]