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.

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

String times get interpreted in a wrong way #348

Open
aboueleyes opened this issue May 18, 2023 · 5 comments
Open

String times get interpreted in a wrong way #348

aboueleyes opened this issue May 18, 2023 · 5 comments

Comments

@aboueleyes
Copy link

aboueleyes commented May 18, 2023

Python Version

3.10

pytest Version

No response

Package Version

No response

Description

class TempTest(TestCase):
    @travel(datetime.datetime(2020, 6, 1, 0, 0, 0))
    def test_time(self):
        print(timezone.now())
        self.assertEqual(datetime.date(2020, 6, 1), timezone.now().date())
        self.assertEqual(timezone.now().date(), datetime.date(2020, 6, 1))

    @travel("2020-06-01")
    def test_time2(self):
        print(timezone.now())
        self.assertEqual(datetime.date(2020, 6, 1), timezone.now().date())
        self.assertEqual(timezone.now().date(), datetime.date(2020, 6, 1))
2020-06-01 00:00:00+00:00
.2020-05-31 22:00:00+00:00
F
======================================================================
FAIL: test_time2 (shahry.core.tests.test_utils.TempTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/time_machine/__init__.py", line 336, in wrapper
    return wrapped(*args, **kwargs)
  File "/app/shahry/core/tests/test_utils.py", line 783, in test_time2
    self.assertEqual(datetime.date(2020, 6, 1), timezone.now().date())
AssertionError: datetime.date(2020, 6, 1) != datetime.date(2020, 5, 31)

for some reason when using"2020-06-01" the time is getting wrong

@adamchainz
Copy link
Owner

This will be due to the way that dateutil parses the datetime, and probably interprets it with the current timezone: https://dateutil.readthedocs.io/en/stable/parser.html

I've been considering removing the dateutil parsing in favour of simpler support with date.fromisoformat() and datetime.isoformat().

If the date was interpreted as a local date oject, would that help you?

@aboueleyes
Copy link
Author

yes, it would be helpful
I guess freezegun have it treated it that way, so it will also make it easier to migrate from freezegun

@adamchainz
Copy link
Owner

No, freezegun uses dateutil, so this would be an incompatibility.

@aboueleyes
Copy link
Author

mm yes but its behavior is correct with me

class TempTest2(TestCase):
    @freeze_time(datetime.datetime(2020, 6, 1, 0, 0, 0))
    def test_time(self):
        print(timezone.now())
        self.assertEqual(datetime.date(2020, 6, 1), timezone.now().date())
        self.assertEqual(timezone.now().date(), datetime.date(2020, 6, 1))

    @freeze_time("2020-06-01")
    def test_time2(self):
        print(timezone.now())
        self.assertEqual(datetime.date(2020, 6, 1), timezone.now().date())
        self.assertEqual(timezone.now().date(), datetime.date(2020, 6, 1))
2020-06-01 00:00:00+00:00
.2020-06-01 00:00:00+00:00
.
----------------------------------------------------------------------
Ran 2 tests in 0.119s

OK

same tests

@Siburg
Copy link

Siburg commented Jul 9, 2023

See #306 . I actually prefer the interpretation of a string to be in the timezone from my settings.

P.S. If it is changed, please treat it as a breaking change; because I have now written many of my tests using the current interpretation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants