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.

Sign up for GitHub

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

Jump to bottom

fake.time_delta is always datetime.timedelta(0) #2077

Open
amingilani opened this issue Jul 29, 2024 · 4 comments
Open

fake.time_delta is always datetime.timedelta(0) #2077

amingilani opened this issue Jul 29, 2024 · 4 comments

Comments

@amingilani
Copy link

  • Faker version: all
  • OS: all

I'm not sure I understand why this is the case. But the expected behvaior as described in the documentation is that fake.time_delta() always returns timedelta(0). I would expect this to be randomized like all the other fake values we generate. If this is intentional, please let me know. I couldn't discussions around this behavior.

Actual behavior

from faker import Faker
Faker.seed(0)
fake = Faker()
for _ in range(5):
  fake.time_delta()
 
datetime.timedelta(0)
datetime.timedelta(0)
datetime.timedelta(0)
datetime.timedelta(0)
datetime.timedelta(0)

Expected behavior

The result should be

datetime.timedelta(days=8041, seconds=60445, microseconds=593254)
datetime.timedelta(days=-9448, seconds=15856, microseconds=620945)
datetime.timedelta(days=7332, seconds=68815, microseconds=994962)
datetime.timedelta(days=-1456, seconds=6174, microseconds=787389)
datetime.timedelta(days=-1833, seconds=11987, microseconds=179397)

Workaround

from faker import Faker
Faker.seed(0)
fake = Faker()
for _ in range(5):
  fake.date_time() - fake.date_time()

datetime.timedelta(days=8041, seconds=60445, microseconds=593254)
datetime.timedelta(days=-9448, seconds=15856, microseconds=620945)
datetime.timedelta(days=7332, seconds=68815, microseconds=994962)
datetime.timedelta(days=-1456, seconds=6174, microseconds=787389)
datetime.timedelta(days=-1833, seconds=11987, microseconds=179397)

I am more than happy to submit a patch if this needs to be fixed.
@stefan6419846
Copy link
Contributor

This has been changed in #907 and only occurs when running this without end_datetime as it seems to choose a seconds value in the range [0, datetime.now() - datetime.now()] in this case, which will basically always map to [0, 0] and thus always generate 0:

faker/faker/providers/date_time/__init__.py

Lines 1837 to 1846 in 554d1aa

def time_delta(self, end_datetime: Optional[DateParseType] = None) -> timedelta:
"""
Get a timedelta object
"""
start_datetime = self._parse_start_datetime("now")
end_datetime = self._parse_end_datetime(end_datetime)
seconds = end_datetime - start_datetime
ts = self._rand_seconds(*sorted([0, seconds]))
return timedelta(seconds=ts)

@amingilani
Copy link
Author

This has been changed in #907 and only occurs when running this without end_datetime as it seems to choose a seconds value in the range [0, datetime.now() - datetime.now()] in this case, which will basically always map to [0, 0] and thus always generate 0:

Thanks for the reply and the additional context @stefan6419846!

While #907 does improve the behavior with end_datetime. I still don't think the behavior when trying to generate a random time_delta should result in non-random values. If an end_datetime is required to output random timedeltas, then it should be a required parameter. But I don't it should be required parameter to get random timedeltas.

As an example, this wouldn't be considered acceptable:

>>> for _ in range(5):
>>>     print(fake.pyint())
0
0
0
0
0

@fcurella
Copy link
Collaborator

I think we need to change the signature of timedelta to make end_datetime mandatory.

@amingilani
Copy link
Author

I can submit a patch for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fcurella @amingilani @stefan6419846