Техническое задание (ТЗ) — что это такое, определение техзадания

А Б В Г Д Е Ё Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю Я

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0-9

Т

Техническое задание – документ, в котором зафиксированы требования к решениям, которые должны быть реализованы в ходе создания сайта или программного обеспечения.

В составлении ТЗ участвуют заказчик совместно с разработчиком. Вклад разработчика в техническое задание заключается в том, чтобы сформулировать конечную цель и понять пожелания заказчика, избежав при этом двусмысленных толкований. Другими словами, исполнитель должен посмотреть на проблему глазами заказчика.

На основании собственноручно утверждённого технического задания, заказчик будет принимать готовую работу. В некоторых случаях ТЗ составляет исполнитель проекта.

Техническое задание включает следующие пункты:

· общая информация (название сайта, перечень необходимых для работы документов),

· назначения и цели будущего сайта или программного обеспечения,

· требования к функционалу сайта,

· уровень безопасности будущего проекта

· дизайн, структура и навигация по сайту,

· контент сайта,

· порядок приема выполненного проекта.

Техническое задание – неотъемлемый инструмент коммуникации между заказчиком и исполнителем, так как позволяет обеим сторонам:

· представить будущий продукт,

· проверить созданный продукт более точно, по пунктам,

· не допустить ошибок или снизить их количество.

Существует и такое мнение, что ТЗ делается в основном для заказчиков, а не для исполнителей. Специалист, профессионально занимающийся созданием сайта или разработкой ПО, прекрасно понимает всю последовательность и продолжительность работы над проектом. Техническое задание таким образом – продолжение принципа «клиент всегда прав».  

Синонимы: нет
Все термины на букву «Т»
Все термины в глоссарии

Шаблон и пример ТЗ на рекламу у Instagram-блогера – для поста и сторис

У сотрудничества с блогерами – две стороны. С одной – кажется, что через них продвигаются все, ну или, по крайней мере, каждая вторая компания – 52 % (хотя цифры очевидно завышены, такой вид продвижения определенно популярен).

С другой стороны, в телеграм-канале «Черный список блогеров» – 26 тысяч подписчиков, и почти каждый день там публикуются посты и скриншоты с очередной неудачной историей сотрудничества с инфлюенсером. Очень многих из этих историй могло бы не произойти, если бы перед началом сотрудничества было четко прописано и согласовано ТЗ на рекламу – а для верности еще и подписан договор о сотрудничестве.

Что прописать в ТЗ и как максимально себя обезопасить от «сюрпризов», рассказал Андрей Калашник, директор по маркетингу сервиса проверки блогеров trendHERO.

Зачем нужно ТЗ на рекламу у блогера

Техническое задание (ТЗ) — это детальная инструкция, которую составляет заказчик для исполнителя. В документе обозначают все условия и детали, значимые для качественного выполнения задания: требования, ограничения, пожелания, сроки и прочее. Чем более тщательно проработано ТЗ, тем выше вероятность получить нужный результат.

Блогеру техническое задание нужно для понимания того, что именно нужно сделать и в какой срок. В инструкции он видит прописанные цели и задачи рекламной кампании. Это позволяет ему создать максимально релевантную рекламу.

Продвинем ваш бизнес

В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров

Как написать ТЗ для Instagram-блогера

Унифицированной формы для технического задания не предусмотрено. Каждый включает в документ то, что считает важным. Руководствоваться можно следующим примером структуры:

• Описание продукта или услуги. Расскажите о вашем продукте все, что важно знать блогеру. Обязательно уточните, какие особенности товара нужно упомянуть в рекламе.
• Ссылки на ваши ресурсы, связанные с продуктом. Дайте ссылки на ваш сайт, профили бренда в соцсетях и любые ресурсы, которые помогут блогеру лучше понять ваш продукт.
• Правильное произношение/написание названия продукта и бренда. Уточните, как правильно произносятся название, какие варианты можно или нельзя употреблять.
• Цель рекламной кампании. Четко пропишите цель, которой вы планируете достичь.
• Формат рекламного контента. Обязательно пропишите, какой тип контента вам нужен — пост, Stories, видео, Reels.
• Требования к визуалу. В этой части опишите всё, что касается фото и видео, цветовой гаммы, особенностей оформления.
• Требования к тексту. Здесь следует уточнить объем текста, количество необходимых ссылок или упоминаний.
• Основные тезисы. Опишите суть рекламного месседжа, основные тезисы. Блогер должен понимать, о чем ему нужно говорить с аудиторией.
• Сроки исполнения. Установите точные сроки предоставления первичного материала на согласование. Обозначьте дату и время публикации.

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

Готовое техническое задание становится приложением к договору о сотрудничестве. Непосредственно в договоре, помимо условий сотрудничества и оплаты, следует указать следующие моменты:

• Ответственность сторон. Пропишите, как действовать в случае, если одна из сторон не выполнит обязательства.
• Обязательное предоставление отчетности. Пропишите в договоре, что после размещения блогер должен предоставить статистику по публикации. Укажите, в какие сроки он должен это сделать. Лучше, если статистика будет предоставлена в видеоформате, а не скриншотами, что исключит вероятность редактирования цифр.

Поскольку при подписании договора блогер подтверждает свое согласие с прилагаемыми документами, согласовать ТЗ нужно до заключения договора.

Пример ТЗ на Stories

1. Описание продукта. Вот документ с подробным описанием продукта (ссылка). Обязательно упомянуть, что наш продукт…
2. Дополнительные материалы. Ссылки на сайт, «ВКонтакте», Instagram, Facebook.
3. Произношение. Наш бренд называется по-английски…, а по-русски…. Продукт можно называть только так… или …, никак иначе.
4. Цель рекламной кампании.
   Привлечение покупателей. Измерять будем по промокодам. В рекламе использовать промокод….
5. Формат. Stories. Нужна серия из трёх сториз. В первом – затронуть проблему и вовлечь во взаимодействие (опрос, беседа в комментариях). Во втором – рассказать о возможном решении. В третьем – дать решение и непосредственно промокод. Примерный сценарий сториз: 1 – …, 2 – …, 3 – ….
6. Требования к визуалу. Цветовое оформление – …. Ракурс – …. Дополнительные требования….
7. Требования к монологу. Содержание…. Стиль общения….
8. Требования к тексту. Количество текста в сторис …, возможные варианты подписей …, расположение текста…, шрифт …, размер ….
9. Основной месседж. Рассказать зрителям, что….
10. Сроки исполнения. …

При составлении технического задания на Stories учитывайте, что длительность историй не превышает 15 секунд. Хотя с недавнего времени Instagram тестирует запуск сторис длительностью до 60 секунд, пока такая функция доступна только отдельным аккаунтам. Не старайтесь передать максимум информации в видео. Определите, что самое важное должен рассказать и показать блогер.

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

Вот как может выглядеть пример готового ТЗ на Stories в Instagram:

Пример ТЗ на сторис

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

Пример ТЗ на пост

Прежде чем писать ТЗ на пост, посмотрите публикации блогера. Выясните, как и о чем он обычно пишет. Если ваш рекламный пост будет сильно отличаться от остального контента в блоге, результаты могут вас огорчить.

Примерный шаблон ТЗ на рекламный пост для блогера Instagram:

1. Продукт. Описание ….
2. Ссылки на дополнительные ресурсы. Сайт …, соцсети …, иные материалы ….
3. Произношение/написание. Образец правильного написания …. Называть продукт можно так …, название бренда употреблять только в полной форме ….
4. Цель рекламной кампании. Повышение узнаваемости и привлечение новых пользователей в аккаунт… Для оценки результатов кампании изучаем статистику публикации – количество просмотров и реакций.
5. Формат рекламного контента. Пост с фото продукта и упоминанием аккаунта.
6. Требования к фотографии. По ссылке примеры фотографий, которые можно использовать. Можно использовать фото блогера с продуктом в руках, но только после согласования и утверждения изображения.
7. Требования к тексту поста. Объём…. Примерная структура …. Обязательные упоминания …. Хештеги …. Стиль изложения …. Упоминания аккаунта…
8. Основные тезисы. Основная суть текста ….
9. Сроки исполнения. …

Вот так выглядит пример ТЗ на пост в Instagram:

Пример ТЗ на пост в Instagram

Чтобы точнее объяснить суть задачи, вы можете в разделе с дополнительными материалами указать рекламные публикации блогера, которые вам понравились. Полистайте профиль и посмотрите, что и как рекламировал блогер ранее. Также можно приложить референсы понравившихся рекламных постов других блогеров.

Частые ошибки при составлении ТЗ для блогеров

• Отсутствие конкретных тезисов. Даже лучший блогер не прочитает ваши мысли. Он не может самостоятельно догадаться, что именно вы хотите отобразить в рекламном месседже. В итоге может получиться совсем не то, на что вы рассчитывали. Поэтому максимально подробно опишите все тезисы, которые должны присутствовать в публикации – главная мысль, обязательные фразы и упоминания и прочее.
• Переизбыток ограничений. Тезисы тезисами, но не стоит требовать неукоснительного соблюдения конкретного сценария. Большое количество ограничений помешает создать интересный и естественный контент. Лучше разрешите блогеру придумать контент на основе ваших тезисов и договоритесь о предварительном согласовании. В этом случае вы можете изложить в ТЗ обязательные для соблюдения моменты, а непосредственно разработку сценария делегировать блогеру с условием согласования контента до размещения.
• Нечеткие дедлайны. Очень важно понятно прописать в ТЗ всё, что касается времени – дату предоставления контента на согласование, дату и точное время размещения, длительность сохранения поста. Если оговорить только дату, блогер может опубликовать пост или Stories в то время, когда аудитория наименее активна, и вся работа окажется напрасной. Или вы рассчитываете на то, что пост останется в профиле блогера надолго, а его удалят спустя пару дней. Все эти моменты стоит уточнить заранее.

Можно ли заказать рекламу у блогера Instagram без технического задания? Безусловно, вы можете побеседовать лично или онлайн и рассказать о пожеланиях или постараться изложить суть сотрудничества в переписке. Однако наличие ТЗ убережет вас от неприятных ситуаций, когда блогер что-то сделал не так или сотрудничество пошло не по плану. Лучше потратить время на составление детального ТЗ, чем запустить неэффективную кампанию и слить бюджет.

Скачать шаблон ТЗ для Instagram-блогера

часовых поясов | Документация Django

Обзор

Когда включена поддержка часовых поясов, Django сохраняет информацию о дате и времени в UTC в базе данных, использует внутренние объекты datetime с учетом часового пояса и переводит их в часовой пояс конечного пользователя в шаблонах и формах.

Это удобно, если ваши пользователи живут более чем в одном часовом поясе, и вы хотите отображать информацию о дате и времени в соответствии с настенными часами каждого пользователя.

Даже если ваш сайт доступен только в одном часовом поясе, это все равно хорошо практика хранения данных в формате UTC в вашей базе данных. Основная причина — светлое время суток. экономия времени (летнее время). Во многих странах есть система перехода на летнее время, когда часы переводятся весной вперед и осенью назад. Если вы работаете по местному времени, вы, вероятно, столкнетесь с ошибками два раза в год, когда происходят переходы. Это, вероятно, не имеет значения для вашего блога, но это проблема, если вы переплатите. или по счету ваших клиентов на один час, два раза в год, каждый год. Решение этой проблемы состоит в том, чтобы использовать в коде UTC и использовать местное время только тогда, когда взаимодействие с конечными пользователями.

Поддержка часовых поясов по умолчанию отключена. Чтобы включить его, установите USE_TZ = True в вашем файле настроек.

Note

В Django 5.0 поддержка часовых поясов будет включена по умолчанию.

Поддержка часовых поясов использует zoneinfo , что является частью стандарта Python. библиотека из Python 3.9. Пакет backports.zoneinfo автоматически устанавливается вместе с Django, если вы используете Python 3.8.

Изменено в Джанго 4.0:

zoneinfo стал реализацией часового пояса по умолчанию. Вы можете продолжать использовать pytz в течение цикла выпуска 4.x через USE_DEPRECATED_PYTZ параметр.

Примечание

Файл settings.py по умолчанию, созданный django-admin startproject включает USE_TZ = True для удобства.

Если вы боретесь с конкретной проблемой, начните с часового пояса ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ.

Концепции

Наивные и осведомленные объекты даты и времени

Объекты Python datetime. datetime имеют атрибут tzinfo , который может использоваться для хранения информации о часовом поясе, представленной в виде экземпляра подкласс datetime.tzinfo . Когда этот атрибут установлен и описывает смещение, объект datetime знает . В противном случае это наивное .

Вы можете использовать is_aware() и is_naive() , чтобы определить, осознанный или наивный.

Когда поддержка часового пояса отключена, Django использует наивные объекты даты и времени в локальном время. Этого достаточно для многих случаев использования. В этом режиме для получения текущее время, вы бы написали:

 импорт даты и времени
сейчас = datetime.datetime.now()
 

Когда поддержка часового пояса включена ( USE_TZ=True ), Django использует объекты datetime с учетом часового пояса. Если ваш код создает объекты даты и времени, они тоже должен быть в курсе. В этом режиме приведенный выше пример становится следующим:

 из часового пояса импорта django. utils
сейчас = часовой пояс.сейчас()
 

Предупреждение

Работа с осведомленными объектами даты и времени не всегда интуитивно понятна. Например, аргумент tzinfo стандартного конструктора datetime не работает достоверно для часовых поясов с летним временем. Использование UTC в целом безопасно; если ты используя другие часовые пояса, вы должны просмотреть зонаинформация документацию тщательно.

Примечание

Объекты Python datetime.time также содержат tzinfo атрибут, и PostgreSQL имеет соответствие времени с типом часового пояса . Однако, как говорится в документации PostgreSQL, этот тип «обладает свойствами, которые привести к сомнительной полезности».

Django поддерживает только наивные объекты времени и вызовет исключение, если вы попытаться сохранить осведомленный объект времени в качестве часового пояса для времени без связанная дата не имеет смысла.

Интерпретация наивных объектов datetime

Когда USE_TZ равно True , Django по-прежнему принимает наивное datetime объекты, чтобы сохранить обратную совместимость. Когда уровень базы данных получает один, он пытается сообщить об этом, интерпретируя его в часовой пояс по умолчанию и выдает предупреждение.

К сожалению, во время перехода на летнее время некоторые даты и время не существуют или двусмысленный. Вот почему вы всегда должны создавать осведомленные объекты даты и времени, когда время поддержка зоны включена. (см. Использование раздела ZoneInfo в файле zoneinfo документы для примеров использования атрибута fold для указания смещение, которое должно применяться к дате и времени во время перехода на летнее время.)

На практике это редко является проблемой. Django дает вам осведомленные объекты даты и времени в моделях и формах, и чаще всего новые объекты datetime создаются из существующие через timedelta арифметика. Единственный datetime, которое часто создается в коде приложения, является текущим временем, а timezone.now() автоматически делает правильная вещь.

Часовой пояс по умолчанию и текущий часовой пояс

Часовой пояс по умолчанию — это часовой пояс, определенный параметром TIME_ZONE параметр.

Текущий часовой пояс — это часовой пояс, который используется для рендеринга.

Вы должны установить текущий часовой пояс на фактический часовой пояс конечного пользователя с помощью активировать() . В противном случае часовой пояс по умолчанию использовал.

Примечание

Как поясняется в документации TIME_ZONE , Django устанавливает переменные среды, чтобы его процесс выполнялся в часовом поясе по умолчанию. Это происходит независимо от значения USE_TZ и текущий часовой пояс.

Когда USE_TZ равно True , это полезно для сохранения обратная совместимость с приложениями, которые по-прежнему полагаются на местное время. Однако, как объяснялось выше, это не полностью надежен, и вы всегда должны работать с осведомленными датами и временем в UTC в вашем собственном коде. Например, используйте отметка времени() и установите для параметра tz значение utc .

Выбор текущего часового пояса

Текущий часовой пояс является эквивалентом текущего языкового стандарта для переводов. Тем не менее, нет никакого эквивалента Accept-Language HTTP-заголовок, который Django может использовать для определения пользовательского часовой пояс автоматически. Вместо этого Django предоставляет выбор часового пояса. функции. Используйте их для построения часового пояса логика выбора, которая имеет смысл для вас.

Большинство веб-сайтов, которые заботятся о часовых поясах, спрашивают пользователей, в каком часовом поясе они живут. и сохранить эту информацию в профиле пользователя. Для анонимных пользователей они используют часовой пояс их основной аудитории или UTC. zoneinfo.available_timezones() предоставляет набор доступных часовых поясов, которые вы можете использовать для построения карты от вероятных местоположений до часовых поясов.

Вот пример, который сохраняет текущий часовой пояс в сеансе. (пропускает обработка ошибок исключительно ради простоты.)

Добавьте следующее промежуточное ПО в MIDDLEWARE :

 import zoneinfo
из django.utils импортировать часовой пояс
класс TimezoneMiddleware:
    def __init__(я, get_response):
        self.get_response = получить_ответ
    def __call__(я, запрос):
        tzname = request.session.get('django_timezone')
        если имя:
            часовой пояс.активировать(zoneinfo.ZoneInfo(tzname))
        еще:
            часовой пояс.деактивировать()
        вернуть self.get_response (запрос)
 

Создайте представление, которое может установить текущий часовой пояс:

 из django.shortcuts import redirect, render
# Подготовьте карту общих мест для выбора часового пояса, который вы хотите предложить.
common_timezones = {
    «Лондон»: «Европа/Лондон»,
    «Париж»: «Европа/Париж»,
    «Нью-Йорк»: «Америка/Нью-Йорк»,
}
определение set_timezone (запрос):
    если request.method == 'POST':
        request. session['django_timezone'] = request.POST['часовой пояс']
        вернуть перенаправление ('/')
    еще:
        вернуть рендеринг (запрос, 'template.html', {'часовые пояса': common_timezones})
 

Включите форму в template.html , которая отправит POST в это представление:

 {% load tz %}
{% get_current_timezone как TIME_ZONE %}

    {% csrf_token%}
    Часовой пояс:
    <выбрать имя="часовой пояс">
        {% для города, tz в часовых поясах %}
        {{ город }}
        {% конец для %}
    
    

 

Ввод с учетом часового пояса в формах

Когда вы включаете поддержку часового пояса, Django интерпретирует дату и время, введенные в формируется в текущем часовом поясе и возвращает осведомленные объекты даты и времени в clean_data .

Преобразованные даты и время, которые не существуют или неоднозначны, поскольку попадают в Переход на летнее время будет отмечен как недопустимые значения.

Вывод с учетом часового пояса в шаблонах

Когда вы включаете поддержку часового пояса, Django преобразует объекты даты и времени с учетом часового пояса в текущий часовой пояс, когда они отображаются в шаблонах. Это очень похоже на локализацию формата.

Предупреждение

Django не преобразует наивные объекты даты и времени, потому что они могут быть двусмыслен, и потому что ваш код никогда не должен создавать наивные даты и время, когда поддержка часового пояса включена. Однако вы можете принудительно преобразовать с помощью шаблонные фильтры, описанные ниже.

Преобразование в местное время не всегда подходит — вы можете выход для компьютеров, а не для людей. Следующие фильтры и теги, предоставляемая библиотекой тегов шаблона tz , позволяет вам контролировать часовой пояс преобразования.

Теги шаблона

Включает или отключает преобразование осведомленных объектов datetime в текущее время зона в содержащемся блоке.

Этот тег имеет те же самые эффекты, что и настройка USE_TZ . что касается механизма шаблонов. Это позволяет более точно контролировать преобразование.

Чтобы активировать или деактивировать преобразование для блока шаблона, используйте:

 {% load tz %}
{% по местному времени на %}
    {{ ценность }}
{% endlocaltime%}
{% местное время выключено %}
    {{ ценность }}
{% endlocaltime%}
 

Примечание

Значение USE_TZ не учитывается внутри {% localtime %} блок.

Устанавливает или сбрасывает текущий часовой пояс в содержащемся блоке. Когда текущий часовой пояс не установлен, применяется часовой пояс по умолчанию.

 {% нагрузки %}
{% часовой пояс "Европа/Париж" %}
    Парижское время: {{ value }}
{% конечный часовой пояс %}
{% часовой пояс Нет %}
    Время сервера: {{значение}}
{% конечный часовой пояс %}
 

Вы можете получить название текущего часового пояса с помощью get_current_timezone тег:

 {% get_current_timezone как TIME_ZONE %}
 

В качестве альтернативы можно активировать tz() контекстный процессор и используйте контекстную переменную TIME_ZONE .

Фильтры шаблонов

Эти фильтры принимают как осведомленные, так и наивные даты и время. В целях преобразования, они предполагают, что наивные даты и время находятся в часовом поясе по умолчанию. Они всегда вернуть осведомленные даты и времени.

Принудительное преобразование одного значения в текущий часовой пояс.

Например:

 {% нагрузки tz %}
{{ значение | местное время }}
 

Принудительное преобразование одного значения в UTC.

Например:

 {% нагрузки tz %}
{{значение|utc}}
 

Принудительное преобразование одного значения в произвольный часовой пояс.

Аргумент должен быть экземпляром tzinfo подкласс или название часового пояса.

Например:

 {% нагрузки tz %}
{{ значение|часовой пояс:"Европа/Париж" }}
 

Руководство по миграции

Вот как перенести проект, который был запущен до того, как Django поддерживает время зоны.

База данных

PostgreSQL

Серверная часть PostgreSQL хранит дату и время в виде отметки времени с часовым поясом . В На практике это означает, что он преобразует дату и время из часового пояса соединения в UTC при хранении и от UTC до часового пояса соединения при извлечении.

Как следствие, если вы используете PostgreSQL, вы можете переключаться между USE_TZ = False и USE_TZ = True свободно. Часовой пояс подключения к базе данных будет установлено на TIME_ZONE или UTC соответственно, так что Django получает правильную дату и время во всех случаях. Вам не нужно выполнять какие-либо данные преобразования.

Другие базы данных

Другие серверные части хранят дату и время без информации о часовом поясе. Если вы переключитесь из USE_TZ = Ложь 9От 0012 до USE_TZ = True , вы должны преобразовать свои данные из местное время в UTC, что не является детерминированным, если ваше местное время имеет летнее время.

Код

Первый шаг — добавить USE_TZ = True в ваши настройки файл. На этом этапе все должно в основном работать. Если вы создаете наивную дату и время объектов в вашем коде, Django сообщает о них, когда это необходимо.

Однако эти преобразования могут завершиться ошибкой при переходе на летнее время, что означает, что вы еще не пользуются всеми преимуществами поддержки часовых поясов. Кроме того, вы, вероятно, столкнуться с несколькими проблемами, потому что невозможно сравнить наивную дату и время с известным датой и временем. Так как Django теперь предоставляет информацию о дате и времени, вы получите исключения везде, где вы сравниваете дату и время, которые исходят от модели или формы с наивной датой и временем, которую вы создали в своем коде.

Итак, второй шаг — рефакторинг вашего кода везде, где вы создаете экземпляр datetime объекты, чтобы сделать их осведомленными. Это можно делать постепенно. django.utils.timezone определяет несколько удобных помощников для совместимости код: сейчас() , is_aware() , is_naive() , make_aware() и make_naive() .

Наконец, чтобы помочь вам найти код, требующий обновления, Django вызывает предупреждение при попытке сохранить наивную дату и время в базе данных:

 RuntimeWarning: DateTimeField ModelName.field_name получил наивный
datetime (2012-01-01 00:00:00), пока активна поддержка часового пояса.
 

При разработке такие предупреждения можно превратить в исключения и получить traceback, добавив в файл настроек следующее:

 import warnings
предупреждения.filterwarnings(
    'ошибка', r"DateTimeField .* получил наивную дату и время",
    RuntimeWarning, r'django\.db\.models\.fields',
)
 

Фикстуры

При сериализации осведомленной даты и времени включается смещение UTC, например:

 "2011-09-01T13:20:30+03:00"
 

Хотя для наивного datetime это не так:

 "2011-09-01T13:20:30"
 

Для моделей с DateTimeField s эта разница делает невозможным написать приспособление, которое работает как со временем, так и без него поддержка зоны.

Фикстуры, сгенерированные с USE_TZ = False или до Django 1.4, используйте «наивный» формат. Если ваш проект содержит такие приборы, после включения времени зона поддержки, вы увидите RuntimeWarning с, когда вы загружаете их. Получить избавившись от предупреждений, вы должны преобразовать свои приборы в «осведомленный» формат.

Вы можете регенерировать приборы с loaddata затем dumpdata . Или, если они достаточно малы, вы можете отредактировать их, добавив смещение UTC, которое сопоставляет ваш TIME_ZONE с каждой сериализованной датой и временем.

Часто задаваемые вопросы

Настройка

1. Мне не нужны несколько часовых поясов. Должен ли я включить поддержку часового пояса?

   Да. Когда поддержка часовых поясов включена, Django использует более точную модель. местного времени. Это защищает вас от незаметных и невоспроизводимых ошибок вокруг переходы на летнее время (DST).

   При включении поддержки часовых поясов вы столкнетесь с некоторыми ошибками, потому что вы используете наивную дату и время, когда Django ожидает знать дату и время. Такой ошибки появляются при запуске тестов. Вы быстро научитесь избегать недействительных операции.

   С другой стороны, ошибок, вызванных отсутствием поддержки часовых поясов, гораздо больше. сложнее предотвратить, диагностировать и исправить. Все, что связано с запланированными задачами или арифметика даты и времени — кандидат на тонкие ошибки, которые вас укусят только один-два раза в год.

   По этим причинам поддержка часовых поясов включена по умолчанию в новых проектах, и вы должны сохранить его, если у вас нет очень веской причины не делать этого.

2. Я включил поддержку часовых поясов. Я в безопасности?

   Возможно. Вы лучше защищены от ошибок, связанных с переходом на летнее время, но вы все равно можете выстрелить себе в ногу, небрежно превратив наивные свидания в осознанные дата и время, и наоборот.

   Если ваше приложение подключается к другим системам — например, если оно запрашивает веб-сервис — убедитесь, что дата и время указаны правильно. Передавать datetime безопасно, их представление должно включать смещение UTC или их значения должны быть в формате UTC (или в обоих!).

   Наконец, наша система календаря содержит интересные пограничные случаи. Например, вы не всегда можете вычесть один год непосредственно из заданной даты:

    >>> импорт даты и времени
   >>> def one_year_before(value): # Неверный пример.
   ... вернуть значение.заменить(год=значение.год - 1)
   >>> one_year_before(datetime.datetime(2012, 3, 1, 10, 0))
   datetime.datetime(2011, 3, 1, 10, 0)
   >>> one_year_before(datetime.datetime(2012, 2, 29, 10, 0))
   Traceback (последний последний вызов):
   ...
   ValueError: день выходит за пределы допустимого диапазона для месяца
    

   Для корректной реализации такой функции необходимо решить, 2012-02-29 минус один год — это 2011-02-28 или 2011-03-01, что зависит от вашего бизнеса. требования.

3. Как мне взаимодействовать с базой данных, которая хранит дату и время по местному времени?

   Установите параметр TIME_ZONE на соответствующий часовой пояс для этой базы данных в настройке DATABASES .

   Это полезно для подключения к базе данных, которая не поддерживает часовые пояса. и это не управляется Джанго, когда USE_TZ равно True .

Устранение неполадок

1. Мое приложение аварийно завершает работу с ошибкой TypeError: не удается сравнить без смещения и datetime с учетом смещения — что не так?

   Давайте воспроизведем эту ошибку, сравнив наивную и осведомленную дату и время:

    >>> из часового пояса импорта django.utils
   >>> осведомлен = часовой пояс.сейчас()
   >>> наивный = часовой пояс.make_naive(осведомленный)
   >>> наивный == знающий
   Traceback (последний последний вызов):
   . ..
   TypeError: невозможно сравнить дату и время без смещения и с учетом смещения
    

   Если вы столкнулись с этой ошибкой, скорее всего, ваш код сравнивает эти два вещей:

   • дата и время, предоставленные Django — например, значение, прочитанное из формы или поле модели. Поскольку вы включили поддержку часовых поясов, он знает.
   • дата-время, сгенерированное вашим кодом, что наивно (иначе вы бы не читая это).

   Как правило, правильным решением является изменение кода для использования вместо даты и времени.

   Если вы пишете подключаемое приложение, которое должно работать независимо от значения USE_TZ , вы можете найти django.utils.timezone.now() полезно. Эта функция возвращает текущий дата и время как наивная дата и время, когда USE_TZ = False , и как осведомленная дата и время, когда USE_TZ = True . Вы можете добавить или вычесть datetime.timedelta по необходимости.

2. Я вижу много RuntimeWarning: DateTimeField получил наивный datetime (ГГГГ-ММ-ДД ЧЧ:ММ:СС) при активной поддержке часового пояса – это плохо?

   Когда включена поддержка часовых поясов, уровень базы данных ожидает получить знает только дату и время из вашего кода. Это предупреждение появляется, когда он получает наивное свидание. Это указывает на то, что вы не закончили перенос своего кода. для поддержки часового пояса. Советы по этому процессу см. в руководстве по миграции.

   Тем временем для обратной совместимости считается, что дата и время находиться в часовом поясе по умолчанию, чего обычно и следует ожидать.

3. now.date() вчера! (или завтра)

   Если вы всегда использовали наивные даты и время, вы, вероятно, полагаете, что можете преобразовать дату и время в дату, вызвав ее date() метод. Вы также считаете, что дата очень похожа на datetime , за исключением того, что он менее точен.

   Все это неверно в среде с учетом часового пояса:

    >>> импорт даты и времени
   >>> импортировать информацию о зоне
   >>> paris_tz = zoneinfo.ZoneInfo("Европа/Париж")
   >>> new_york_tz = zoneinfo.ZoneInfo("Америка/Нью-Йорк")
   >>> Париж = datetime.datetime(2012, 3, 3, 1, 30, tzinfo=paris_tz)
   # Это правильный способ преобразования между часовыми поясами.
   >>> new_york = paris.astimezone(new_york_tz)
   >>> париж == нью_йорк, париж.дата() == нью_йорк.дата()
   (Правда, Ложь)
   >>> париж - нью_йорк, париж.дата() - нью_йорк.дата()
   (datetime.timedelta (0), datetime.timedelta (1))
   >>> Париж
   datetime.datetime(2012, 3, 3, 1, 30, tzinfo=zoneinfo.ZoneInfo(key='Европа/Париж'))
   >>> Нью-Йорк
   datetime.datetime(2012, 3, 2, 19, 30, tzinfo=zoneinfo.ZoneInfo(key='Америка/Нью-Йорк'))
    

   Как видно из этого примера, одна и та же дата и время имеет разные даты в зависимости от часовой пояс, в котором он представлен. Но настоящая проблема в другом фундаментальный.

   Datetime представляет момент времени . Это абсолютно: это не зависит ни на что. Напротив, дата — это календарная концепция . Это период времени, границы которого зависят от часового пояса, в котором находится дата считается. Как видите, эти два понятия принципиально разные, и преобразование даты и времени в дату не является детерминированной операцией.

   Что это означает на практике?

   Как правило, следует избегать преобразования даты и времени в дата . Например, вы можете использовать дату . фильтр шаблона, чтобы отображать только часть даты даты и времени. Этот фильтр будет преобразовать дату и время в текущий часовой пояс перед его форматированием, чтобы результаты отображались корректно.

   Если вам действительно нужно выполнить преобразование самостоятельно, вы должны убедиться, datetime сначала преобразуется в соответствующий часовой пояс. Обычно это будет текущий часовой пояс:

    >>> из часового пояса импорта django.utils
   >>> timezone. activate(zoneinfo.ZoneInfo("Азия/Сингапур"))
   # В этом примере мы устанавливаем часовой пояс Сингапура, но вот как
   # в общем случае вы получите текущий часовой пояс.
   >>> current_tz = часовой пояс.get_current_timezone()
   >>> местный = париж.astimezone(current_tz)
   >>> местный
   datetime.datetime(2012, 3, 3, 8, 30, tzinfo=zoneinfo.ZoneInfo(key='Азия/Сингапур'))
   >>> местная.дата()
   datetime.date(2012, 3, 3)
    

4. Я получаю сообщение об ошибке « Являются ли определения часовых поясов для вашей базы данных установлены? »

   Если вы используете MySQL, см. раздел Определения часовых поясов. из примечаний MySQL для получения инструкций по загрузке определений часовых поясов.

Usage

1. У меня есть строка "2012-02-21 10:28:45" и я знаю, что она находится в "Европа/Хельсинки" часовой пояс. Как мне превратить это в осознание дата и время?

   Здесь нужно создать требуемый экземпляр ZoneInfo и прикрепить его к наивная дата и время:

    >>> импорт зоныинформации
   >>> из django. utils.dateparse импортировать parse_datetime
   >>> наивный = parse_datetime("2012-02-21 10:28:45")
   >>> naive.replace(tzinfo=zoneinfo.ZoneInfo("Европа/Хельсинки"))
   datetime.datetime(2012, 2, 21, 10, 28, 45, tzinfo=zoneinfo.ZoneInfo(key='Европа/Хельсинки'))
    

2. Как узнать местное время в текущем часовом поясе?

   Ну, первый вопрос, а тебе это действительно нужно?

   При общении с людьми следует использовать только местное время. слой шаблона предоставляет фильтры и теги для преобразования даты и времени в часовой пояс по вашему выбору.

   Кроме того, Python знает, как сравнивать известные даты и время, принимая во внимание счет UTC смещается при необходимости. Это намного проще (и, возможно, быстрее) чтобы написать всю свою модель и просмотреть код в формате UTC. Итак, в большинстве случаев дата и время в UTC возвращаются на django.utils.timezone.now() будет достаточный.

   Однако для полноты картины, если вам действительно нужно местное время в текущем часовом поясе, вот как его можно получить:

    >>> из часового пояса импорта django. utils
   >>> часовой пояс.местное время(часовой пояс.сейчас())
   datetime.datetime(2012, 3, 3, 20, 10, 53, 873365, tzinfo=zoneinfo.ZoneInfo(key='Европа/Париж'))
    

   В этом примере текущий часовой пояс "Европа/Париж" .

3. Как просмотреть все доступные часовые пояса?

   zoneinfo.available_timezones() предоставляет набор всех действительных ключей для Часовые пояса IANA, доступные для вашей системы. См. документы для использования соображения.

`dayjs.tz` не является идемпотентом с датами в летнее время, если сейчас не летнее время. Он собирает ссылки на все места, на которые вы могли бы обратить внимание, выискивая опасную ошибку.

 > dayjs('2020-08-08T00:00:00.000Z').toString()
//=> 'Сб, 08 августа 2020 г., 00:00:00 по Гринвичу'
> dayjs('2020-08-08T00:00:00.000Z').tz('Америка/Чикаго').toString()
//=> 'Пт, 07 августа 2020 г., 23:00:00 по Гринвичу'
> dayjs('2020-08-08T00:00:00.000Z').tz('Америка/Чикаго').tz('Америка/Чикаго').toString()
//=> 'Пт, 07 августа 2020 г., 22:00:00 по Гринвичу'
> dayjs('2020-08-08T00:00:00.000Z').tz('Америка/Чикаго').tz('Америка/Чикаго').tz('Америка/Чикаго').toString()
//=> 'Пт, 07 августа 2020 г., 21:00:00 по Гринвичу'
 

 > dayjs('2020-08-08T00:00:00.001Z').tz('UTC') .tz().tz('UTC'). toString()
//=> 'Пт, 07 августа 2020 г., 21:00:00 по Гринвичу'
> dayjs('2020-08-08T00:00:00.001Z').tz('Америка/Чикаго').tz('UTC').tz().toString()
//=> 'Пт, 07 августа 2020 г., 21:00:00 по Гринвичу'
> dayjs('2020-08-08T00:00:00.001Z').tz().tz().tz().toString()
//=> 'Пт, 07 августа 2020 г., 21:00:00 по Гринвичу'