[Django] #32147: timezone error when casting a naive date in a Daylight Saving Time Change
Django
--------------------------------------+--------------------------
Reporter: WolfTammer | Owner: nobody
Type: Bug | Status: assigned
Component: Utilities | Version: 3.1
Severity: Normal | Keywords: timezone
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--------------------------------------+--------------------------
When you use a model with datetime with a timezone active and naive data
as input, it raise the follow error:
{{{
File "<basepath>/lib/python3.7/site-packages/pytz/tzinfo.py", line 234, 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 = "te...@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
--
Ticket URL: <https://code.djangoproject.com/ticket/32147>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: WolfTammer | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 3.1
(models, ORM) |
Severity: Normal | Resolution: invalid
Keywords: timezone | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: assigned => closed
* resolution: => invalid
* component: Utilities => Database layer (models, ORM)
Comment:
Thanks for this ticket, however Django cannot decide automatically what to
do with such dates, see
[https://docs.djangoproject.com/en/3.1/topics/i18n/timezones
/#interpretation-of-naive-datetime-objects Interpretation of naive
datetime objects]. You can handle this with `make_aware(..., is_dst=...)`.
Closing per TicketClosingReasons/UseSupportChannels.
--
Ticket URL: <https://code.djangoproject.com/ticket/32147#comment:1>
Django
Reporter: WolfTammer | Owner: nobody
Type: Bug | Status: closed
Component: Utilities | Version: 3.1
Severity: Normal | Resolution: invalid
Keywords: timezone | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by WolfTammer):
* component: Database layer (models, ORM) => Utilities
Old description:
New description:
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 = "te...@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
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32147#comment:2>
Django
Reporter: WolfTammer | Owner: nobody
Type: Bug | Status: closed
Component: Utilities | Version: 3.1
Severity: Normal | Resolution: invalid
Keywords: timezone | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32147#comment:3>
Django
Reporter: WolfTammer | Owner: nobody
Type: Bug | Status: closed
Component: Utilities | Version: 3.1
Severity: Normal | Resolution: invalid
Keywords: timezone | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* cc: Aymeric Augustin (added)
Comment:
Replying to [comment:3 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32147#comment:4>
Django
Reporter: WolfTammer | Owner: nobody
Type: Bug | Status: closed
Component: Utilities | Version: 3.1
Severity: Normal | Resolution: invalid
Keywords: timezone | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by WolfTammer):
Replying to [comment:5 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/32147#comment:6>