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 wit
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 amb
True. I think
>>>>> "supports_timezones" should be False. Does anyone know why it's True? Is
>>>>> it just an historical artifact?
>>>>>
>>>>>
>>>>> Finally, I have read the document that describes "to_python",
>&
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 existing Django query builder.
>
> I didn'
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 datetimes as
>> strings, and I didn't wa
;
>>>> --
>>>> Aymeric Augustin.
>>>>
>>>>
>>>>
>>>> On 11 sept. 2011, at 23:18, Aymeric Augustin wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Given the positive feedback received here and on IRC
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 datetimes as
> strings, and I didn't want to duplicate the parsing code. All database
> backends ar
s my branch to trunk:
>>>> https://bitbucket.org/aaugustin/django/compare/..django/django
>>>>
>>>> I've read a lot of code in django.db, and also the documentation of
>>>> PostgreSQL, MySQL and SQLite regarding date/time types.
>>>>
>&
gt; goal is to guarantee backwards-compatibility when USE_TZ = False.
>>>
>>> At first they failed because runtests.py doesn't set os.environ['TZ'] and
>>> doesn't call time.tzset() , so the tests ran with my system local time. I
>>> f
, since everything is supposed to be in UTC internally when USE_TZ
>> is True, it is theoretically to get rid of os.environ['TZ'] and
>> time.tzset(). They are only useful to make timezone-dependant functions
>> respect the TIME_ZONE setting. However, for back
s better to keep them and interpret naive datetimes in
> the timezone defined by settings.TIME_ZONE (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,
>
40, Aymeric Augustin wrote:
> 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
On Sep 8, 5:55 am, Kirit Sælensminde (kayess)
wrote:
> There is also a Django time field. How to handle this is kind of hard
> as having a timezone on a time field may not make much sense. At the
> moment it is up to application code to combine this with a date in a
> sane manner. If Django switc
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
> .
>
> Example
On Sep 6, 10:47 pm, Aymeric Augustin
wrote:
> 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
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 projects.
>
> This is
> 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
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:
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.
@A
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
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 converting on output.
>
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 req
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 m
23 matches
Mail list logo
