Inconsistency between datetime.now() and time.time()

The following code snippet

import time
import freeze gun
from datetime import datetime 

with freezegun.freeze_time("1970-01-01 00:00"):
    print(datetime.now())
    print(datetime.fromtimestamp(time.time()))

prints out the following when run in the timezone Europe/Berlin (CET)

1970-01-01 00:00:00
1970-01-01 01:00:00

The expected result would be 1970-01-01 00:00:00 in both cases.

What seems to happen is that time.time() returns the unix-time which corresponds to 1970-01-01 00:00:00 UTC, i.e. time.time() == 0. When converting it to a datetime object, a time-zone shift is applied. This however is inconsistent with datettime.now().

In general, what is the assumption about the time zone of the argument passed to freeze_time? Is it assumed to be in UTC or in the local time zone?

[adaitche]

The indent is incorrect in your example I assume?

I am not sure what you mean, the indenting seems fine to me. Could you elaborate?

In general freezegun is rather buggy in this respect and people disagree what the behavior should be. I think UTC is the only logical default like you also seem to expect.

I personally would prefer assuming the local timezone, if the timezone is not explicitly specified. This fits my use case more and seems to be more inline with what Python does: it returns datetimes in the local timezone by default. But assuming UTC is also fine.

In any case (whether the datetime passed to freeze_time is assumed to be in UTC or in the local timezone), I think the result of datetime.now() anddatetime.fromtimestamp(time.time()) should be the same. If UTC is assumed, then currently the result of datetime.now() is not correct as it should return the datetime in the local timezone, i.e. with an offset to the datetime passed to freeze_time.

I just haven’t had time to work on freezegun for a long time. A good start would be a comprehensive set of tests for what we want the end result to be. Can this example be converted to a unit test?

I have submitted a pull request with the tests, which currently fail of course. The second test assumes that the datetime passed to freeze_time is in UTC.

[boxed]

I guess the only way to make everything make sense is to ALWAYS pass the timezone you want somehow. You could pass "local" if you want the local, but if it’s explicit then the confusion would go away. We would have to have a deprecation warning for the current API then and then make it illegal.