timezone error when casting a naive date in a Daylight Saving Time Change

[Clara]

When you use a model with datetime with a timezone active and naive data as input, it raise the follow error:

Traceback (most recent call last):
  File "<my_path>/tests/test_users.py", line 235, in test_login_change_hour
    created_at = "2020-10-25 02:00:01"
[...]
  File "<env_path>/lib/python3.7/site-packages/django/utils/timezone.py", line 234, in make_aware
    return timezone.localize(value, is_dst=is_dst)
  File "<env_path>/infojuiceapi2/lib/python3.7/site-packages/pytz/tzinfo.py", line 363, in localize
    raise AmbiguousTimeError(dt)
pytz.exceptions.AmbiguousTimeError: 2020-10-25 02:00:01

The steps to reproduce are:

1. Use a model with datetime: In this example, we are going to create a user model that extends AbstractUser, but you could use any model with a datetime field

class User(AbstractUser):
    class Meta:
        db_table = 'my_user'

    created_at = models.DateTimeField(default=timezone.now)
    updated_at = models.DateTimeField(auto_now=True)
    last_password_change = models.DateTimeField(null=True)

2. Create an object with a string naive date:

    User.objects.create(
        email = "test@amail.it",
        username = "user_25",
        created_at = "2020-10-25 02:00:01"
    )

• The timezone settings are:

TIME_ZONE = 'Europe/Rome'
USE_TZ = True

Database configuration has not timezone set

[Mariusz Felisiak]

Thanks for this ticket, however Django cannot decide automatically what to do with such dates, see ​Interpretation of naive datetime objects. You can handle this with make_aware(..., is_dst=...).

Closing per TicketClosingReasons/UseSupportChannels.

[Clara]

I was going to write a pull request with the posible solution, Can I? It's just if the error is in the Daylight Saving Time Change, don't use pytz. I didn't have time enought to fork the repository create the issue.

[Mariusz Felisiak]

Replying to WolfTammer:

I was going to write a pull request with the posible solution, Can I? It's just if the error is in the Daylight Saving Time Change, don't use pytz. I didn't have time enought to fork the repository create the issue.

We shouldn't decide for users, this may not be an expected behavior for them.

[Aymeric Augustin]

I can confirm. "Don't use pytz" will eventually lead to "assume the value is in DST / not in DST", which we want to avoid. The error is raised on purpose because the input is ambiguous.

If you care about such values, you should write an input that includes time zone information. No one does this in practice because the problem only happens one hour per year.

If you want the whole history, look at #2626 and related mailing-list discussions.

[Clara]

Replying to Aymeric Augustin:

I can confirm. "Don't use pytz" will eventually lead to "assume the value is in DST / not in DST", which we want to avoid. The error is raised on purpose because the input is ambiguous.

If you care about such values, you should write an input that includes time zone information. No one does this in practice because the problem only happens one hour per year.

If you want the whole history, look at #2626 and related mailing-list discussions.

I should write another ticket or modify this with other unittest. My problem is not when you create an object with an aware datetime, I can understand you waypoint in that case, BUT the error comes when I save a datetime with timezone, then I try to retrieve the datetime from DB. It should work, because I specified the timezone in the database settings. I don't think doing a timezone.localize() is a good idea, instead it should be done a replace(tzinfo=timezone) because we are sure that database data is in that timezone. Should I open another ticket or modify this? Or is also a correct behaviour this one?