Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple calls to new Date() should return a fixed time #225

Closed
ItalyPaleAle opened this issue Mar 26, 2022 · 2 comments
Closed

Multiple calls to new Date() should return a fixed time #225

ItalyPaleAle opened this issue Mar 26, 2022 · 2 comments
Labels
behaviour mismatch Different behaviour to Workers runtime
Milestone

Comments

@ItalyPaleAle
Copy link

In a "real" Workers environment, creating new Date objects or returning the current time always return the same value for every call while performing a request. This applies to the new Date() constructor, methods like Date.now(), etc: they return the current time (technically, the time the request was received at), and then subsequent calls return the same value. (Documentation)

In Miniflare, this behavior is not observed. Instead, multiple calls to methods like Date.now() return different values.

Ideally, Miniflare should mirror the behavior of the "real" Workers environment.

@mrbbot
Copy link
Contributor

mrbbot commented Apr 3, 2022

Hey! 👋 Thanks for raising this.

Initially, I made the decision not to implement this as spectre attacks aren't as big of a deal for local development. Additionally, I thought it might be useful to allow users to measure execution times for different parts of their workers during development.

However, you're right, this is a behaviour mismatch. Now that we have a per request context, it should be possible to implement this. I seem to remember that the returned time advanced on any async I/O, but I can't seem to find the docs for it anymore.

If people want to measure execution times, they should be able to use the profiling provided by the Node.js Inspector.

@mrbbot mrbbot added this to the 2.5.0 milestone Apr 3, 2022
@mrbbot mrbbot added the behaviour mismatch Different behaviour to Workers runtime label Apr 3, 2022
@ItalyPaleAle
Copy link
Author

As I think a bit more about this, and applying Hyrum's law, I wonder if the old behavior (having Date always represent the current time) should be kept available for example using a flag? I suspect that there will be at least some people who depend on that behavior, maybe for their unit tests.

@mrbbot mrbbot modified the milestones: 2.5.0, 2.6.0 May 27, 2022
@mrbbot mrbbot closed this as completed in a50b968 Jun 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
behaviour mismatch Different behaviour to Workers runtime
Projects
None yet
Development

No branches or pull requests

2 participants