Opened 23 months ago
Closed 23 months ago
#34214 closed New feature (duplicate)
Bug in default for TimeField when using a timezone
Reported by: | Pierre Anquetil | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 4.1 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Hi !
In Python, a datetime.time instance can have a timezone.
For a Timefield model in Django, which represents a datetime.time instance, it should be logic to use a datetime.time to set a default.
In fact, it's partially possible :
models.TimeField(null=False,blank=False,default=time(18,30,0,0,None)) or models.TimeField(null=False,blank=False,default=time(18,30,0,0)) works
But when you want to use a timezone on your default, it does not work :
models.TimeField(null=False,blank=False,default=time(18,30,0,0,tz.gettz('Europe/Paris'))) dont works.
In Django 3.1, the error was that it was not possible to use <= between timefieldand Datetimefield. So i guess the error was that when setting a timezone on a time, when the default of timefield had a timezone set, django was converting it in a datetimefield.
In Django 4.1, the error message changed : NameError : name 'tzfile' is not defined.
In my models.py, i use :
from dateutil import tz
...
heure_midi=models.TimeField(null=False,blank=False,default=time(18,30,0,0,tz.gettz('Europe/Paris')))
It's transformed in the migration in :
import datetime
...
migrations.AddField(
model_name='restaurant',
name='heure_soir',
field=models.TimeField(default=datetime.time(18, 30, tzinfo=tzfile('Europe/Paris'))),
),
the import datetime works, but there is no import tz or anything, and the tz.gettz has been changed in "tzfile"
Change History (1)
comment:1 by , 23 months ago
Component: | Uncategorized → Database layer (models, ORM) |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
Type: | Uncategorized → New feature |
It's documented that: "Django only supports naive time objects and will raise an exception if you attempt to save an aware time object, as a timezone for a time with no associated date does not make sense."
Duplicate of #18691 (see also #26183).