You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repo and believe that this is not a duplicate.
OS version and name: macOS 11.6.1
Pendulum version: 2.1.2, 3.0.0a0
Issue
When using the pendulum.test context in tests, the local timezone is getting set to Toronto when using pendulum.today(). To see this behavior, add this test to tests/date/test_diff.py:
You can see that .now() returns a UTC timezone but .today() returns Toronto. (Or at least, this is what I'm seeing, even though I'm not in the Toronto timezone, I'm in the Los Angeles timezone.) As a result, pendulum.today().date() evaluates to (timezone-naive) February 29, because it's still February in Toronto when it's midnight on March 1 in UTC.
This is occurring in some existing tests in test_diff, for example test_diff_for_humans_now_and_month, but seems it is being masked by another bug (see #606) that causes the time difference to be calculated incorrectly (or at the very least inconsistently) for months that do not have 31 days.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Issue
When using the
pendulum.test
context in tests, the local timezone is getting set to Toronto when usingpendulum.today()
. To see this behavior, add this test totests/date/test_diff.py
:Alternatively, try:
You can see that
.now()
returns a UTC timezone but.today()
returns Toronto. (Or at least, this is what I'm seeing, even though I'm not in the Toronto timezone, I'm in the Los Angeles timezone.) As a result,pendulum.today().date()
evaluates to (timezone-naive) February 29, because it's still February in Toronto when it's midnight on March 1 in UTC.You can see this in a REPL too:
This is occurring in some existing tests in
test_diff
, for exampletest_diff_for_humans_now_and_month
, but seems it is being masked by another bug (see #606) that causes the time difference to be calculated incorrectly (or at the very least inconsistently) for months that do not have 31 days.The text was updated successfully, but these errors were encountered: