Opened 3 years ago

Closed 3 years ago

#21300 closed New feature (wontfix)

Allow DateTimeField to return a naive datetime

Reported by: Bryce Groff Owned by: Aymeric Augustin
Component: Forms Version: master
Severity: Normal Keywords: forms DateTimeField
Cc: brycegroff@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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?

Attachments (1)

21300-first-and-incomplete-attempt.diff (15.9 KB) - added by Aymeric Augustin 3 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by Bryce Groff

Cc: brycegroff@… added

comment:2 Changed 3 years ago by Tim Graham

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)?

comment:3 Changed 3 years ago by Bryce Groff

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

comment:4 Changed 3 years ago by Tim Graham

Resolution: wontfix
Status: newclosed

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

comment:5 Changed 3 years ago by Bryce Groff

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

comment:6 Changed 3 years ago by Aymeric Augustin

Resolution: wontfix
Status: closednew

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.

comment:7 Changed 3 years ago by Aymeric Augustin

Owner: changed from nobody to Aymeric Augustin
Status: newassigned

comment:8 Changed 3 years ago by Bryce Groff

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?

comment:9 Changed 3 years ago by Aymeric Augustin

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.

comment:10 Changed 3 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:11 Changed 3 years ago by Aymeric Augustin

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

For instance, when using PostgreSQL, DateTimeFields 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 formDateField 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.

comment:12 Changed 3 years ago by Aymeric Augustin

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.

Changed 3 years ago by Aymeric Augustin

comment:13 Changed 3 years ago by Aymeric Augustin

Resolution: wontfix
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.
Back to Top