Opened 3 years ago

Closed 3 years ago

#21300 closed New feature (wontfix)

Allow DateTimeField to return a naive datetime

Reported by: brycegroff Owned by: aaugustin
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


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 aaugustin 3 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by brycegroff

  • Cc brycegroff@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 3 years ago 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)?

comment:3 Changed 3 years ago 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.


comment:4 Changed 3 years ago by timo

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:5 Changed 3 years ago by brycegroff

If one should need a datetime form field to not be run through the Django timezone features, this form field can help:

comment:6 Changed 3 years ago by aaugustin

  • Resolution wontfix deleted
  • Status changed from closed to new

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 aaugustin

  • Owner changed from nobody to aaugustin
  • Status changed from new to assigned

comment:8 Changed 3 years ago 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?

comment:9 Changed 3 years ago 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.

comment:10 Changed 3 years ago by timo

  • Triage Stage changed from Unreviewed to Accepted

comment:11 Changed 3 years ago by aaugustin

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 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.

Changed 3 years ago by aaugustin

comment:13 Changed 3 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from assigned to closed

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

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