Skip to content

Deprecate windows time64_t#5032

Open
dybucc wants to merge 1 commit intorust-lang:mainfrom
dybucc:time64-windows-deprecation
Open

Deprecate windows time64_t#5032
dybucc wants to merge 1 commit intorust-lang:mainfrom
dybucc:time64-windows-deprecation

Conversation

@dybucc
Copy link
Copy Markdown

@dybucc dybucc commented Mar 26, 2026

Description

Functionality related to the Windows time64_t has been deprecated in favor of a single, 64-bit wide time_t. This has also required some work into getting rid of the conditional compilation uses of time_t on GNU target environments, and tweaking the max_align_t type, as that seemed to provide an incoherent interface in Windows with mingw32.

During this work, what seems like some incoherences in the CI pipeline where found out, and have been addressed as well. This mostly consists of a step where mingw32 was being installed and possibly "fixed" but that would never run because it relied on environment variables that were only visible in the runner once the job coming after the one setting up the Rust toolchain ran. This has now been removed in favor of not performing any checks, as CI logs indicate this has been the case for some time.

The FIXME comment on the tier 1 platform support for Windows with GNU has also been removed as no segfaults were observed.

There's not yet an issue open specifically for deprecation of non-64-bit wide time and offset-related values, so the linked issue in the deprecation notice for time64_t is still pending.

Sources

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

Functionality related to the Windows `time64_t` has been deprecated in
favor of a single, 64-bit wide `time_t`. This has also required some
work into getting rid of the conditional compilation uses of `time_t` on
GNU target environments, and tweaking the `max_align_t` type, as that
seemed to provide an incoherent interface in Windows with mingw32.

During this work, what seems like some incoherences in the CI pipeline
where found out, and have been addressed as well. This mostly consists
of a step where mingw32 was being installed and possible "fixed" but
that would never run because it relied on environment variables that
were only visible in the runner once the job coming after the one
setting up the Rust toolchain ran. This has now been removed in favor of
not performing any checks, as CI logs seem to have been running for some
time without this.

The FIXME comment on the tier 1 platform support for Windows with GNU
has also been removed as no segfaults were observed.
@rustbot rustbot added A-CI Area: CI-related items S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Mar 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-CI Area: CI-related items S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants