fix: interpret Local-kind mock time against configured zone#1055
Merged
Conversation
The mock time system stored a `Local`-kind input instant as-is in the constructor and normalized it via `ToUniversalTime()` in `SetTo`. Both interpret a `Local` instant against the *host machine's* time zone, so `DateTime.Now`/`UtcNow` and `DateTimeOffset.Now`/`UtcNow` depended on the host zone when a custom `LocalTimeZone` differed from it - defeating the library's determinism guarantee. Normalize `Local`-kind input to UTC using the mock's configured `_localTimeZone` in both the constructor and `SetTo`, so `_now` is always UTC and every consumer is corrected at the boundary. `Unspecified` is still treated as UTC and already-`Utc` values are untouched. Update the `Use(...)` XML-doc remarks to state how `Local`-kind input is interpreted, and add regression tests asserting the result depends only on the configured zone, not the host.
vbreuss
force-pushed
the
fix/local-kind-timezone-bug
branch
from
c8e0d7e to
d69a5e3
Compare
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The mock time system stored a
Local-kind input instant as-is in the constructor and normalized it viaToUniversalTime()inSetTo. Both interpret aLocalinstant against the host machine's time zone, soDateTime.Now/UtcNowandDateTimeOffset.Now/UtcNowdepended on the host zone when a customLocalTimeZonediffered from it - defeating the library's determinism guarantee.Normalize
Local-kind input to UTC using the mock's configured_localTimeZonein both the constructor andSetTo, so_nowis always UTC and every consumer is corrected at the boundary.Unspecifiedis still treated as UTC and already-Utcvalues are untouched.Update the
Use(...)XML-doc remarks to state howLocal-kind input is interpreted, and add regression tests asserting the result depends only on the configured zone, not the host.DateTimeOffsetsupport toITimeSystem#1039