Remove everything except Instant from bevy_utils::time
#17158
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bushrat011899
added
D-Trivial
BenjaminBrienen
approved these changes
Jan 5, 2025
alice-i-cecile
added
X-Contentious
alice-i-cecile
approved these changes
Jan 5, 2025
alice-i-cecile
added
S-Ready-For-Final-Review
mrchantey
pushed a commit
to mrchantey/bevy
that referenced
this pull request
Feb 4, 2025
…e#17158) # Objective - Contributes to bevyengine#11478 - Contributes to bevyengine#16877 ## Solution - Removed everything except `Instant` from `bevy_utils::time` ## Testing - CI --- ## Migration Guide If you relied on any of the following from `bevy_utils::time`: - `Duration` - `TryFromFloatSecsError` Import these directly from `core::time` regardless of platform target (WASM, mobile, etc.) If you relied on any of the following from `bevy_utils::time`: - `SystemTime` - `SystemTimeError` Instead import these directly from either `std::time` or `web_time` as appropriate for your target platform. ## Notes `Duration` and `TryFromFloatSecsError` are both re-exports from `core::time` regardless of whether they are used from `web_time` or `std::time`, so there is no value gained from re-exporting them from `bevy_utils::time` as well. As for `SystemTime` and `SystemTimeError`, no Bevy internal crates or examples rely on these types. Since Bevy doesn't have a `Time<Wall>` resource for interacting with wall-time (and likely shouldn't need one), I think removing these from `bevy_utils` entirely and waiting for a use-case to justify inclusion is a reasonable path forward.
rcorre
added a commit
to rcorre/matchbox
that referenced
this pull request
Apr 27, 2025
Bevy 0.16 was released a few days ago, update `bevy_matchbox` to use that. There weren't any major changes affecting matchbox that I could see. The only things I had to adjust to were: - `utils::Duration` was removed in favor of `core::Duration`: bevyengine/bevy#17158 - Logging now requires a feature - `ecs::world::Command` moved to `prelude::Command` See: https://bevyengine.org/news/bevy-0-16/.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
Solution
Instantfrombevy_utils::timeTesting
Migration Guide
If you relied on any of the following from
bevy_utils::time:DurationTryFromFloatSecsErrorImport these directly from
core::timeregardless of platform target (WASM, mobile, etc.)If you relied on any of the following from
bevy_utils::time:SystemTimeSystemTimeErrorInstead import these directly from either
std::timeorweb_timeas appropriate for your target platform.Notes
DurationandTryFromFloatSecsErrorare both re-exports fromcore::timeregardless of whether they are used fromweb_timeorstd::time, so there is no value gained from re-exporting them frombevy_utils::timeas well. As forSystemTimeandSystemTimeError, no Bevy internal crates or examples rely on these types. Since Bevy doesn't have aTime<Wall>resource for interacting with wall-time (and likely shouldn't need one), I think removing these frombevy_utilsentirely and waiting for a use-case to justify inclusion is a reasonable path forward.