You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Occasionally we have a need to generate a date where the only requirement is that it be in the past or in the future. This requires a bit of inexpressive boilerplate each time.
This proposes to add:
fake.futureDate(): generates a JavaScript Date later than Date.now()
fake.pastDate(): generates a JavaScript Date earlier than Date.now()
Alternatively, we could nest these under fake.date.{future,past}? But that would require either making a breaking API change to fake.date() or doing that weird pattern where fake.date is simultaneously a function and an object, which I'm not a fan of.
(Ideally, it would be cool to validate somehow that when these two methods are used, the clock is stubbed, since such a thing should never be used with nondeterministic, actual clock time, but that sounds like something that would be a nightmare to implement since we'd have to make some hacky assumptions about stubbing libraries, etc. It probably isn't worth it.)
The text was updated successfully, but these errors were encountered:
Occasionally we have a need to generate a date where the only requirement is that it be in the past or in the future. This requires a bit of inexpressive boilerplate each time.
This proposes to add:
fake.futureDate()
: generates a JavaScriptDate
later thanDate.now()
fake.pastDate()
: generates a JavaScriptDate
earlier thanDate.now()
Alternatively, we could nest these under
fake.date.{future,past}
? But that would require either making a breaking API change tofake.date()
or doing that weird pattern wherefake.date
is simultaneously a function and an object, which I'm not a fan of.(Ideally, it would be cool to validate somehow that when these two methods are used, the clock is stubbed, since such a thing should never be used with nondeterministic, actual clock time, but that sounds like something that would be a nightmare to implement since we'd have to make some hacky assumptions about stubbing libraries, etc. It probably isn't worth it.)
The text was updated successfully, but these errors were encountered: