feat(date): introduce global refDate instead of passing it every time

[king-in-it]

Describe the bug

When using faker.seed with a value, e.g. faker.seed(123), faker should always give back the same values for the faker functions, but this is not the case for faker.date.past(). It uses a fixed amount of time to go back, but that's always the current date minus that fixed time. So for example calling faker.date.past() today would give a different result when calling it tomorrow.

The issue is not present when providing the parameters maxYears and refDate, e.g. faker.date.past(30, new Date(2022,0)).

Reproduction

1. Set the faker seed: faker.seed(123);
2. Call faker.date.past() (without parameters)
3. Rerunning the same code provides a different value for that same faker.date.past()

See https://stackblitz.com/edit/typescript-qiclti for a reproduction.

Additional Info

@faker-js/faker version used: 6.1.2

[Shinigami92]

This is because the refDate is default to Date.now() as the docs say.
Not sure if this is a bug, just the default params 🤔

[king-in-it]

Indeed, it has to do with calling the toDate function (https://github.com/faker-js/faker/blob/main/src/date.ts#L47) with the refDate being undefined, which causes the refDate to be a new Date() (

faker/src/date.ts

Line 13 in b10f00c

date = new Date();

). I'm using the faker.seed to give predictable results (e.g. in conjunction with Jest snapshots), but using faker.date.past() with current implementation is unpredictable...

[ST-DDT]

IMO this is not a bug. With a fixed refDate it is predictable.

If you pass a refDate yourself and do result.getTime() - refDate.getTime() then this will always result in the same value for a given seed.
We use now as a default to ensure the value actually contains dates that are "soon/future" (relative to now/refDate) whenever you are calling it.
As for the jest snapshots, I think you can avoid the issue with property matchers:
https://jestjs.io/docs/snapshot-testing#property-matchers

[king-in-it]

Thanks for the snapshots tip, but I don't want to set this manually in each snapshot whenever a date is involved. That's why the faker.seed is useful. Also the documentation states: "If you want consistent results, you can set your own seed", but if faker.date.past() changes each time, that is not very consistent. When a seed is set, then instead of assigning new Date() perhaps the Date can be initialized by other values of the faker lib to have a fixed ref date?

[ST-DDT]

When a seed is set, then instead of assigning new Date() perhaps the Date can be initialized by other values of the faker lib to have a fixed ref date?

We could do that of course or even hardcode it. However we have to weight two different concerns here.
Getting expected values without parameters and context, getting fixed values. (Both are reproducible)

If you are calling faker.date.future() and you get 1970-01-01T13:37:42Z I guest most users would be surprised.
IMO having a parameter that gives you control over your "expectation" of future/past is a good way to get good values.

If you are interested in explicitly setting the refDate "globally" instead of passing it to the method every time, then you could open a PR for that.

[king-in-it]

Setting the refDate globally would be a good solution for this, because then this can be set near the faker.seed function call! Thanks for all the input!

[JontyMC]

+1