[Django] #21300: Allow DateTimeField to return a naive datetime

16 views
Skip to first unread message

Django

unread,
Oct 21, 2013, 9:10:50 PM10/21/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-----------------------------+---------------------------------
Reporter: brycegroff | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Keywords: forms DateTimeField
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+---------------------------------
Currently if USE_TZ = True is set in the settings file, the
forms.DateTimeField will always return a timezone aware datetime. I ran
into a situation where I needed to have the datetime localized by another
field on the form and needed to subclass the DateTimeField to overwrite
the to_python method.

Maybe we could add a kwarg naive=False that would return a naive datetime
in the cleaned_data if set?

--
Ticket URL: <https://code.djangoproject.com/ticket/21300>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 21, 2013, 9:16:23 PM10/21/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------

Reporter: brycegroff | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by brycegroff):

* cc: brycegroff@… (added)
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0


--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:1>

Django

unread,
Oct 30, 2013, 10:55:16 AM10/30/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------

Reporter: brycegroff | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by timo):

I'm not sure the additional complexity of this is worth it. Do you think
your use case is common enough that others will benefit from this (perhaps
you could describe it a little more)?

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:2>

Django

unread,
Oct 31, 2013, 1:23:03 PM10/31/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------

Reporter: brycegroff | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by brycegroff):

Sure, the situation I came across was this:

I have a model that has a timezone field and a datetime. The datetime
should be calculated based on the timezone in the model. Ever other
datetime in the project is fine to use the timezone in the settings. To
not use the settings timezone however required subclassing the
DateTimeField in forms. This is fine, however it does add a lot of extra
code, and now I have to keep track of my own version of DateTimeField
(which I doubt will be a big deal).

If the complexity is not worth it, I understand. I think there may be
other people that could use this feature, but I will not push it farther
than this. I think posting a solution to this problem here may be a good
alternative, as I could not find an answer with google. I do not want to
spam trac though, so let me know if this is a good place or not.

Thanks,
Bryce

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:3>

Django

unread,
Nov 4, 2013, 2:00:09 PM11/4/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: nobody
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timo):

* status: new => closed
* resolution: => wontfix


Comment:

Feel free to post your solution or a pointer to it here.

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:4>

Django

unread,
Nov 5, 2013, 1:03:48 PM11/5/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: nobody
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by brycegroff):

If one should need a datetime form field to not be run through the Django
timezone features, this form field can help: http://pastebin.com/j4TnnHTS

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:5>

Django

unread,
Nov 5, 2013, 2:47:23 PM11/5/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------

Reporter: brycegroff | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):

* status: closed => new
* resolution: wontfix =>


Comment:

I'd like to have a second look at this idea, but don't get your hopes too
high, I could confirm the wontfix once I've had more time to think about
it.

Roughly, I'm thinking of adding a `naive` keyword argument to the form and
model DateTimeField (I need it on the form field too at least for the
admin). This is going to have far reaching, and probably messy,
consequences.

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:6>

Django

unread,
Nov 5, 2013, 3:18:28 PM11/5/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: aaugustin
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):

* status: new => assigned
* owner: nobody => aaugustin


--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:7>

Django

unread,
Nov 5, 2013, 4:38:03 PM11/5/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: aaugustin
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by brycegroff):

Sure, if you would like to have more discussion out of band, I think you
should be able to see my email. Is this something that warrants a mailing
list discussion?

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:8>

Django

unread,
Nov 5, 2013, 5:31:24 PM11/5/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: aaugustin
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:

Keywords: forms DateTimeField | Triage Stage:
Has patch: 0 | Unreviewed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by aaugustin):

Well, the requirements are pretty clear to me: one must be able to disable
selectively the time zone code in model and form DateTimeFields.

I've encountered this problem myself with the model layer: I had to
interact with a third party database whose schema I couldn't control, and
the data was in local time. Your use case is also interesting: ironically,
time zone support makes it slightly more difficult!

Since I implemented time zone support in Django, I feel qualified to make
a decision -- not because this is my territory or anything, just because I
know how I designed it.

If I think it can work, I'll upload a patch for review.

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:9>

Django

unread,
Nov 13, 2013, 11:54:23 AM11/13/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: aaugustin
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: forms DateTimeField | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timo):

* stage: Unreviewed => Accepted


--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:10>

Django

unread,
Dec 4, 2013, 5:29:01 AM12/4/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: aaugustin
Type: New feature | Status: assigned
Component: Forms | Version: master

Severity: Normal | Resolution:
Keywords: forms DateTimeField | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by aaugustin):

The main problem in practice is... the global `USE_TZ` setting :( How
surprising.

For instance, when using PostgreSQL, `DateTimeField`s return aware
datetimes because database cursors are configured to add time zone
information to all datetimes:

{{{
def create_cursor(self):
cursor = self.connection.cursor()
cursor.tzinfo_factory = utc_tzinfo_factory if settings.USE_TZ else
None
return cursor
}}}

----

Of course, there's a good reasons for making `USE_TZ` global: the
template, form and model layers must agree on the mode (naive or aware) in
which Django is running.

But it could be useful to provide a way to work with naive datetimes in
the database and form layers. The template layer already provides a
sufficient API.

That would require:
- a way to override `TIME_ZONE` and `USE_TZ` on a per-database basis.
Currently it's already possible, although undocumented, to override
`TIME_ZONE`.
- a way to override `USE_TZ` in model and form`DateField` and
`DateTimeField` on a per-field basis.

This would be documented as an advanced use case and it would be up to
each project that takes advantage of this to ensure that the right models
are used on the right databases. In practice, the main use case is to
access third-party databases that store date times in an way that's
incompatible with the main project settings.

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:11>

Django

unread,
Dec 4, 2013, 6:04:14 AM12/4/13
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: aaugustin
Type: New feature | Status: assigned
Component: Forms | Version: master

Severity: Normal | Resolution:
Keywords: forms DateTimeField | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by aaugustin):

I looked at the ORM layer and there's a dozen places where it's going to
be very hard to inject the `USE_TZ` setting. See attached patch.

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:12>

Django

unread,
Jan 3, 2014, 3:43:10 PM1/3/14
to django-...@googlegroups.com
#21300: Allow DateTimeField to return a naive datetime
-------------------------------------+-------------------------------------
Reporter: brycegroff | Owner: aaugustin
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix

Keywords: forms DateTimeField | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):

* status: assigned => closed
* resolution: => wontfix


Comment:

Re-closing wontfix because I didn't have a better idea. Sorry.

--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:13>

Reply all
Reply to author
Forward
0 new messages