Faker dates are not reproducible with fixed seed.

[luisjakon]

Pre-Checks

• Follow our Code of Conduct.
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Faker issue and not related to a combination with another package.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.
• I am willing to provide a PR.

Describe the bug

Faker-generated dates using past and recent functions are not reproducible given a fixed seed. Seems like there is a slight drift in the regeneration....

Is there a way to fix the generated dates with a given seed?

Minimal reproduction code

  // Run multiple times independently
  faker.seed(200)
  console.log('past: '+faker.date.past())

past: 2022-11-17T17:54:54.896Z
past: 2022-11-17T17:57:42.305Z 
past: 2022-11-17T17:58:07.209Z
past: 2022-11-17T17:58:29.581Z
past: 2022-11-17T17:58:54.245Z 

Additional Context

No response

Environment Info

System:
    OS: macOS 13.2.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 10.65 GB / 64.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.13.0 - ~/.volta/tools/image/node/18.13.0/bin/node
    Yarn: 4.0.0-rc.39 - ~/.volta/tools/image/yarn/4.0.0-rc.39/bin/yarn
    npm: 8.19.3 - ~/.volta/tools/image/node/18.13.0/bin/npm
  Browsers:
    Brave Browser: 109.1.47.186
    Chrome: 110.0.5481.100
    Safari: 16.3
  npmPackages:
    @faker-js/faker: 8.0.0-alpha.0 => 8.0.0-alpha.0

Which module system do you use?

• CJS
• ESM

Used Package Manager

pnpm

[Shinigami92]

We have already introduced #1757 in v8 (alpha)
Oh it's not released yet, we might need to release a new alpha for this

Also why does the refDate parameter not work for your case?
Could you provide us some more info what you did expect instead and how we could solve that for you? Please note that we didn't want to pin the refDate to a fixed date by default as this would result in a non future maintained state were e.g. a call to soon or future could slip into the past.

[luisjakon]

Thnxs @Shinigami92. The refDate works great! I was using the non-refDate api before and ran into this problem before learning about the refDate parameter. Thank you again.

[matthewmayer]

i think this could be added as a note to the refDate parameter in the documentation? Something like "If a refDate is provided, dates generated with a fixed faker.seed() value won't change between runs."

[ST-DDT]

I would phrase it independently from seed something like this:

Required (here or via faker.refDateSource), if reproducible results are needed. If defined, the returned value will be relative to the given date. If absent, the returned value will be relative to now.

[matthewmayer]

Is refDateSource documented anywhere?

[ST-DDT]

The methods on the faker instance itself, dont have a documentation yet.

My idea was mostly to give our users the hint that such a property exists.

[matthewmayer]

I think it could be useful to add a section to the Usage Guide about this. I made PR #1892 for that. Then maybe the 4 faker.date.* methods that have refDate could link to this section for more details.

[luisjakon]

Hi. Two questions:

1. Not clear and I haven't tested this, but if the faker.defaultRefDate is unset, will it behave as if it was never set to begin with or is it memoized at some point?
2. Would it make sense to extend the faker.seed signature to include the defaultRefDate as well? This might help with the documentation and understanding upfront...

[ST-DDT]

1. If faker.defaultRefDate hasn't been set or has been reset, then it will default to () => new Date().
2. Might be useful. Although maybe not as the only way to set it, otherwise it might be impossible to change the defaultRefDate without also changing the seed. Is there a need to do that? 🤔 Created a separate issue to discuss that: Merge faker.defaultRefDate with faker.seed #1895