Thanks Paul, Anssi, Mikhail and Daniel for reviewing the proposal!
Here are some answers to your remarks.
On 3 sept. 2011, at 20:19, Paul McMillan wrote:
> My main concern with your proposal is that it may require two
> different code paths for a lot of code.
Currently, my best guess is:
- limited changes in the models layer
- some new code in the forms and template layers (if USE_TZ: …)
- most of the duplication will be in the tests, because I have to test
everything with and without USE_TZ.
Of course, I can't be sure before actually writing the code :)
> I would like this new code to eventually become the default setting,
> but acknowledge that there doesn't seem to be a good way to do that
> and maintain our current backwards compatibility (and external
> dependency) policy.
I'm going to use the same trick used by USE_L10N and explained by Anssi: set
USE_TZ to False in global_settings.py and to True in the template of
settings.py. This preserves backwards compatibility but the new code is the
default for new projects.
On 3 sept. 2011, at 21:19, Anssi Kääriäinen wrote:
> - Performance: The USE_L10N setting made rendering tables consisting
> of numbers much slower (see #14290 for example). It would be good if
> there wasn't any major regressions due to this.
With USE_TZ, rendering a datetime will be slower because of the conversion to
local time. I have no idea of the performance of pytz. I'll do some benchmarks.
> - Concurrency: My quick reading of the documentation of pytz
> suggests that this should not be a problem. But your implementation
> would be thread safe, right? The main problem here is localizing the
> timestamps.
Certainly, the implementation must be thread safe, because requests may run
concurrently in different threads for users in different timezones. I'm pretty
sure it will work out of the box, and it will be even more isolated if I can
avoid setting os.environ['TZ'] and calling time.tzset().
> - I want to save the following information in the database: The
> meeting starts at 08:00 localtime 2011-09-04. Localtime is based on
> some other information, maybe the location of the meeting room.
> (...) it would be very valuable if there were a way to save just a
> plain datetime information in the database if the user so chooses.
In my opinion, and more importantly in PostgreSQL's implementation, a DateTime
represents a "point in time", in an absolute sense — ignoring relativistic
effects :)
For your example, I support Daniel's suggestion: use a DateField and a
TimeField, plus a way to obtain the time zone (like a foreign key to the
meeting room). That's exactly the information you said you wanted to store :)
I've hesitated a lot to add a "naive=False/True" keyword argument to
DateTimeField. Right now, I'm still convinced that mixing naive and aware
DateTimes in the same application a recipe for disaster and that Django
shouldn't facilitate it.
On 4 sept. 2011, at 00:48, Mikhail Korobov wrote:
> I have one concern though. Can you please explain why is USE_TZ option better
> than introducing e.g. UtcDateTimeField?
In short, Django shouldn't provide two different ways to represent a "point in
time". Quoting the Zen of Python: "There should be one-- and preferably only
one --obvious way to do it."
> USE_TZ=True will break all existing code (including external apps) which
> relies on django 1.3 documented DateTimeField behavior, this can be scary and
> will introduce a lot of "if getattr(settings, USE_TZ, False): #..."
> statements in external apps for backwards compatibility.
This is an interesting question. For backwards compatibility, if a
DateTimeField is set to a naive datetime (like datetime.datetime.now()) and
USE_TZ is True, the value should be interpreted in local time and a warning
should be raised.
With this rule, I believe that most code should work just fine with or without
USE_TZ, thanks to duck typing. Basically, what works on a naive datetime also
works on an aware datetime, including timedelta arithmetic.
Of course, applications dedicated to dealing with timezones may break. If
you're using one, you should probably stick with USE_TZ = False.
> Good UtcDateTimeField implementation can be released as a separate package
> (and then eventually included in django itself). This way existing django
> projects will be able to use it without waiting for a release and backwards
> compatibility won't be broken. Are there obstacles in django itself that
> prevent this option?
In short, my proposal can't be implemented outside of core because it requires
a modification of the template engine.
If it could, I'm sure someone would have done it already — ticket #2626 has
been open for five years.
In fact, I tried to implement these ideas without modifying Django in my
current project. The result is way too messy for publication, let alone for
eventual inclusion in Django. My entry point in the template engine is
django.utils.formats.localize, and I'm monkey patching it to convert datetimes
to local time. This means I'm mixing localization and timezones. I have to set
TIME_ZONE = 'UTC' to get UTC in the database and introduce another setting,
LOCAL_TIME_ZONE, for the local time of the project. Finally my developers must
never forget to use custom DateTimeFields in models and forms, as well as a
custom ModelAdmin base class, or UTC data shows up in the admin. It's totally
unwieldy.
On 4 sept. 2011, at 12:34, Daniel Swarbrick wrote:
> re storing UTC in Postgres: this is somewhat moot,
> since Postgres stores timestamps internally as a UTC Julian date
> regardless of which timezone the client connection uses
Under PostgreSQL, I assume I have to use a TIMESTAMP WITH TIME ZONE and set the
connection's timezone to UTC if I want non-Django applications using the same
database to obtain correct results, regardless of their connection's timezone.
To be honest, this is pure speculation; I must check this for each database
engine.
Best regards,
--
Aymeric Augustin.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
