faker.time module to simplify time (not datetime) usecases

[douglasg14b]

Clear and concise description of the problem

Generating fakes specifically for times, not necessarily dates. These will only produce times, and not consider dates.

The date fucntions do perform this utility to some degree but require additional work to achieve which could be baked into a time module directly.

Suggested solution

in module faker.date or in a new module faker.time it would have fucntions for:

• faker.time.between
• faker.time.after
• faker.time.range
• ....etc

These should accept a format argument that allows the time output to be formatted as 24/12h time (or others)

Alternative

Users build their own time fucntions that work on top of faker.date

Additional context

Naive examples from my own use:

function getFakeTime(options?: { from?: Date; to?: Date } = {}) {
    const from = options?.from || '2024-01-01T00:00:00.000Z';
    const to = options?.to || '2024-01-01T23:59:59.999Z';

    return faker.date.between({from, to});
}

function getFake24hTime(time?: Date) {
    const dateTime = time || getFakeTime();
    return dateTime.toISOString().slice(11, 16);
}

function getFake24hTimeRange() {
    const from = getFakeTime();
    const to = getFakeTime({from});
    return {
        from: getFake24hTime(from),
        to: getFake24hTime(to),
    }
}

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes (:+1:) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest