std.Io: Standardize the epoch as 1970-01-01T00:00:00Z #25814
Closed
+5
−4
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.
This is only one way of addressing this. Considering this change was intentional, as before #25592,
time.nanoTimestampdid perform this conversion to a Unix timestamp on Windows, this may not be the intended fix.See #25776 (comment) for context (cc @castholm)
Enforcing a standard epoch in the Io.Clock API allows usage to be simplified, as it allows users to not have to constantly deal with implementation-defined epochs.
For example, this change fixes #25776 because on Windows (which previously would return a value relative to a different epoch), the crypto.Certificate code would compare a Unix timestamp to the value returned by the
.realclock. To fix this while keeping the implementation-defined epoch, every usage of Clock.real would have to be audited and deal with converting between epochs in a platform-specific way.Note also that Windows is the only odd-one out in the current implementation: