Re: Check-in #7 / Multiple timezone support for datetime representation

Hi Preston, On 30 oct. 2011, at 17:07, ptone wrote: > I do think a better label than "value" could be used for the > thread.local for the current timezone, as this is really a thread > global - something less ambiguous and conflict prone would be better > IMO. I used this name for consistency

Re: Check-in #7 / Multiple timezone support for datetime representation

I just did an initial scan through: https://bitbucket.org/aaugustin/django/compare/..django/django and this looks like a great piece of work. I do think a better label than "value" could be used for the thread.local for the current timezone, as this is really a thread global - something less

Re: Check-in #7 / Multiple timezone support for datetime representation

cribes "to_python", >>>>> "value_to_string", and r"get_(db_)?prep_(value|save|lookup)". The next >>>>> step is to adjust these functions in DateFieldField, depending on the >>>>> value of settings.USE_TZ. >>>>> >>

Re: Check-in #5 / Multiple timezone support for datetime representation

On Oct 23, 7:16 pm, Aymeric Augustin wrote: > > Converters can be > > registered per-column - the SELECT query would need to be tweaked to > > hint to the SQLite libs to call the registered converter. I'm not sure > > if that would be too intrusive to the

Re: Check-in #5 / Multiple timezone support for datetime representation

On 18 oct. 2011, at 14:48, Daniel Swarbrick wrote: > On Oct 16, 11:48 am, Aymeric Augustin > wrote: >> Hello, >> >> I've implemented the storage and retrieval of aware datetime objects in >> SQLite. This involved some refactoring, because SQLite returns

Check-in #6 / Multiple timezone support for datetime representation

t;>>>> >>>>> Given the positive feedback received here and on IRC, I've started the >>>>> implementation. >>>>> >>>>> Being most familiar with mercurial, I've forked the Bitbucket mirror. >>>>> This page that compares my branch to t

Check-in #5 / Multiple timezone support for datetime representation

gt;> PostgreSQL, MySQL and SQLite regarding date/time types. >>>> >>>> I've written some tests that validate the current behavior of Django. >>>> Their goal is to guarantee backwards-compatibility when USE_TZ = False. >>>> >>>> At first t

Check-in #4 / Multiple timezone support for datetime representation

call time.tzset() , so the tests ran with my system local time. I >>> fixed that in setUp and tearDown. Maybe we should call them in runtests.py >>> too for consistency? >>> >>> By the way, since everything is supposed to be in UTC internally when >>

Check-in #3 / Multiple timezone support for datetime representation

only useful to make timezone-dependant functions >> respect the TIME_ZONE setting. However, for backwards compatibility (in >> particular with third-party apps), it's better to keep them and interpret >> naive datetimes in the timezone defined by settings.TIME_ZONE (instead o

Check-in #2 / Multiple timezone support for datetime representation

ONE (instead of rejecting them > outright). For this reason, I've decided to keep os.environ['TZ'] and > time.tzset() even when USE_TZ is True. > > Best regards, > > -- > Aymeric Augustin. > > > On 3 sept. 2011, at 17:40, Aymeric Augustin wrote: > >>

Check-in #1 / Multiple timezone support for datetime representation

"Multiple timezone support for datetime representation" > wasn't picked up in 2011 and 2010. Although I'm not a student and the summer > is over, I'd like to tackle this problem, and I would appreciate it very much > if a core developer accepted to mentor me during this work, GSoC-sty

Re: Multiple timezone support for datetime representation

I just wanted to chime in with a couple of extra notes here. I won't comment on most of it as I think it's all spot on :) On Sep 3, 10:40 pm, Aymeric Augustin wrote: > Django should use timezone-aware UTC datetimes internally >

Re: Multiple timezone support for datetime representation

2011/9/6 Paul McMillan : >> 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

Re: Multiple timezone support for datetime representation

> 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. This isn't gonna work because your new

Re: Multiple timezone support for datetime representation

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:

Re: Multiple timezone support for datetime representation

I'm wholeheartedly on +1 on this. @Anssi Kääriäinen, re your localtime meeting example: this type of scenario has been discussed on this list previously, and the generally acknowledged solution is to use separate date and time fields, neither of which (on their own) have a concept of timezone.

Re: Multiple timezone support for datetime representation

Great job on summarizing the issue! I have one concern though. Can you please explain why is USE_TZ option better than introducing e.g. UtcDateTimeField? USE_TZ=True will break all existing code (including external apps) which relies on django 1.3 documented DateTimeField behavior, this can be

Re: Multiple timezone support for datetime representation

On Sep 3, 9:19 pm, Paul McMillan 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

Re: Multiple timezone support for datetime representation

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

Multiple timezone support for datetime representation

Hello, The GSoC proposal "Multiple timezone support for datetime representation" wasn't picked up in 2011 and 2010. Although I'm not a student and the summer is over, I'd like to tackle this problem, and I would appreciate it very much if a core developer accepted to mentor me during