Allow DateTimeField to return a naive datetime

[Bryce Groff]

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?

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

[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

[Tim Graham]

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

[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

[Aymeric Augustin]

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.

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

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

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

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

[Aymeric Augustin]

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