Skip to content

Conversation

@squeek502
Copy link
Member

@squeek502 squeek502 commented Nov 4, 2025

This is only one way of addressing this. Considering this change was intentional, as before #25592, time.nanoTimestamp did 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 .real clock. 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:

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 ziglang#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 `.real` clock. 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:

- WASI uses the 1970-01-01T00:00:00Z epoch: https://github.com/WebAssembly/WASI/blob/9ea0e7534f46f0c39f28b386fa2becf00923a857/legacy/preview0/docs.md?plain=1#L30-L32
- POSIX uses the 1970-01-01T00:00:00Z epoch: https://pubs.opengroup.org/onlinepubs/9699919799/ and https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_125
@squeek502
Copy link
Member Author

Closing in favor of #25817

@squeek502 squeek502 closed this Nov 5, 2025
@squeek502 squeek502 removed the request for review from andrewrk November 5, 2025 00:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Can't fetch package on Windows

1 participant