Денис Егоров

Для получения текущего времени с временной зоной (локализованное время) нужно использовать now() не из datetime, а из django.utils.timezone:

from django.utils.timezone import now

Чтобы преобразовать уже локализованный datetime в другую временную зону (например во временную зону пользователя):

from django.utils.timezone import now, pytz
user_timezone = pytz.timezone(user.timezone or settings.TIME_ZONE)
now().astimezone(user_timezone)

Если у вас нелокализованный datetime и вы хотите добавить ему информацию о временной зоне:

from datetime import datetime
from django.utils.timezone import pytz
user_timezone = pytz.timezone(user.timezone or settings.TIME_ZONE)
user_timezone.localize(now())

Для того, чтобы Djagno использовало временные зоны для полей Date/Datetime нужно, они должны быть включены в настройках:

TIME_ZONE = 'Europe/Moscow'
USE_TZ = True

Почти на всех больших проектах мне удавалось избегать использования .raw(), по этому я спросил вас, что там внутри. Почти наверняка есть обходные пути.

Для того, чтобы быть уверенным, что запрос не будет выполнен несколько раз, его можно сразу превратить в список:

object_list = list(MyModel.objects.raw(...))

Для выполнения prefetch_related в raw запросах обычно используют prefetch_related_objects, хотя эта функция в Django не документирована:

from django.db.models.query import prefetch_related_objects
object_list = list(MyModel.objects.raw(...))
prefetch_related_objects(raw_qs, ['fk_field', 'another_fk_field', ...])

Для изучения когда и какие запросы выполняются удобно пользоваться консолью debugsqlshell из django debug toolbar (которую вы скорее всего используете).

14px, если воспользоваться банальным усреднением по web-проектам за последние пару лет.

Неожиданно нашлась хорошая табличка сравнения разных библиотек визуализации: http://socialcompare.com/en/comparison/javascript-graphs-and-charts-libraries

Если на каждый лайк делать по запросу, выйдет тяжело. Тяжелее чем то же самое сразу на сервере.
Мне не удалось придумать адекватную систему кеширования для подобных элементов. На Хабре и других высоконагруженных проектах делаются запросы типа

SELECT ... FROM votes WHERE user_id=<id> AND object_id IN(...)

Один запрос на все лайки одного типа. N запросов, если на странице N типов объектов.

Можно попробовать хранить (или дублировать) голоса в NoSQL, например в Redis с ключами типа «post_{post_id}_{user_id}» и вытаскивать их одним запросом mget… Но вы сначала запуститесь, и поймите что именно получение голосов у вас является узким местом, а потом городите такие штуки.

Нужен. Небольшое объяснение тут. Идея любопытная. Но, конечно, всё ломается когда пытаешься вставить какую-нибудь форматированную фигню из буфера обмена…