On Sep 3, 9:19 pm, Paul McMillan <p...@mcmillan.ws> wrote: > Hi Aymeric, > > First, thanks for all your triage work on track, it's very much > appreciated. This is a large proposal, but I think it covers the issue > pretty completely. > > I agree with your approach of using UTC internally and converting on output. > > My main concern with your proposal is that it may require two > different code paths for a lot of code. I have no objection to the > dependency on pytz, but I don't want this to result in pytz-aware code > that diverges significantly from the non-pytz default path. > > 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. > > This isn't my area of expertise, so I'm not a good mentor candidate, > but I'd be excited to help you with this project where I can. > > I'm wholeheartedly +1 on this.
I'm +1 also. Some notes: - 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. I suggest making a few testcases upfront For example one could be a fetch of 10000 objects from the DB. Another one is to then render the 10000 objects. The last one is quite slow already if USE_L10N is True, so there is hope this could actually improve that case. - 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. - 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. I do not want this information to change if there is a DST change. In the proposal you are saying that you are not going to tackle this problem. However, 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. The user is then free to interpret if it means 08:00 in Helsinki/Europe timezone, or something else. Storing in UTC does not allow for this because of DST changes. I guess I am saying that having a models.DatetimeField(plain=True) would be a good thing... - The default for USE_TZ should be False if not specified but True for new projects. That is, it is included in the settings template as True but it is False in the global_settings.py. The design looks good. I am very interested in this. One more piece in making Django more useful in the enterprise setting. I hope you find somebody qualified to mentor your project. - Anssi -- 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.
