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.
* cc: brycegroff@… (added)
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:1>
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>
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>
* 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>
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>
* 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>
* status: new => assigned
* owner: nobody => aaugustin
--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:7>
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>
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>
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/21300#comment:10>
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>
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>
* 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>