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.

@Aymeric Augustin, 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 (client TZ
offset is dynamically added/subtracted at insert/update/select-time).
In the case of MySQL and SQLite however, it is a valid point.

I can understand some people's concerns about the dependency
requirement of pytz in order to achieve this. It would have been great
to see pytz added to the standard Python libs in 3.x, since (IMHO)
it's such a fundamental requirement of any language these days. In any
case, it will be great to see Django's international date/time
handling be on a par with its L10N and I18N features.

On Sep 4, 12:48 am, Mikhail Korobov <kmik...@googlemail.com> wrote:
> 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 scary
> and will introduce a lot of "if getattr(settings, USE_TZ, False): #..."
> statements in external apps for backwards compatibility.
>
> 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?

-- 
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.

Reply via email to