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

Что дальше?

Далее проходит следующий этап работы — редактирование с автором. Вносятся поправки в статью, согласно ТЗ. И все продолжается, пока статья не будет устраивать вас на 99,9%. Техническое задание, своего рода, юридический документ, на который вы можете ссылаться, когда автор в порыве своего вдохновения отклонился от темы, либо раздул объем статьи, либо вовсе забыл раскрыть одну из важных тем.  

О чем важно помнить?

От написания технического задания для копирайтера зависит конечный продукт — статья. Статья — это инструмент заработка, в который мы вкладываемся заранее. Поэтому нужно осознавать всю важность и ценность правильно собранного и прописанного ТЗ. Особенно важно это правило для конкурентных ниш.  Логика проста: выше конкуренция по ключу → нужна больше и качественнее статья → нужно много слов + хороший автор → нужно больше денег на статью → выше риски и больше потеряешь, если статья не выстрелит. Но в таких нишах гораздо больше шансов получить высокий трафик, который потом можно конвертировать в высокий доход. Поэтому к написанию технического задания нужно подходить с холодной головой и горячим сердцем. Четко анализировать и добавлять уместный креатив. Дерзайте!

• Об авторе
• Недавние публикации

Роман Макаров

Основатель, генеральный директор и руководитель отдела роста в HighTime Agency

11 лет продвигает SaaS-компании в США, Франции, Германии, ОАЭ и России. Увеличил поток трафика и триалов в 3 раза для компании EdTech. Создал 2 онлайн-журнала с нуля и продал с мультипликатором x33.

Роман Макаров недавно публиковал (посмотреть все)

tz — документация dateutil 2.8.2

Этот модуль предлагает реализации часового пояса, подклассы абстрактного datetime.tzinfo тип. Существуют классы для обработки формата tzfile. файлы (обычно находятся в /etc/localtime , /usr/share/zoneinfo , д.), строка окружения TZ (во всех известных форматах), заданные диапазоны (с помощью от относительных дельт), часовой пояс локальной машины, часовой пояс с фиксированным смещением и UTC часовой пояс.

Объекты

dateutil.tz. Всемирное координированное время

Удобный экземпляр dateutil.tz.tzutc .

Новое в версии 2.7.0.

Функции

dateutil.tz. гетц ( имя = нет )

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

Эта функция предназначена для получения подкласса tzinfo . который лучше всего представляет часовой пояс, который будет использоваться, если POSIX Переменная TZ была установлена ​​на то же значение.

Если в не передается аргумент или пустая строка, gettz , местное время возвращается:

 >>> получить()
tzfile('/etc/localtime')
 

Эта функция также является предпочтительным способом сопоставления ключей базы данных IANA tz. до tzfile объектов:

 >>> gettz('Тихий океан/Киритимати')
tzfile('/usr/share/zoneinfo/Pacific/Kiritimati')
 

В Windows стандарт расширен за счет включения специфичных для Windows имена зон, предоставленные операционной системой:

 >>> gettz('Стандартное время Египта')
tzwin('Стандартное время Египта')
 

При передаче спецификации часового пояса строки в стиле GNU TZ возвращается цстр объект:

 >>> gettz('AEST-10AEDT-11,M10.1.0/2,M4.1.0/3')
tzstr('AEST-10AEDT-11,M10.1.0/2,M4.1.0/3')
 

Параметры:	имя — название часового пояса (IANA, или, в Windows, ключи Windows), местоположение tzfile(5) файл zoneinfo или TZ часовой пояс с переменным стилем спецификатор. Пустая строка, без аргумента или None интерпретируется как местное время.
Возвращает:	Возвращает экземпляр одного из dateutil tzinfo подклассы.

Изменено в версии 2.7.0: После версии 2.7.0 любые два вызова gettz с использованием одного и того же входные строки вернут один и тот же объект:

 >>> tz.gettz('Америка/Чикаго') is tz.gettz('Америка/Чикаго')
Истинный
 

Помимо повышения производительности, это гарантирует, что Семантика «той же зоны» используется для даты и времени в той же зоне.

гетц. нокаш ()

Некэшированная версия gettz

классметод gettz. cache_clear ()

dateutil.tz. свернуть ( dt , свернуть = 1 ) [источник]

Предоставляет единый интерфейс для назначения атрибута fold datetime как до, так и после реализации PEP-495.

Параметры:	fold — значение атрибута fold в возвращаемой дате и времени. Этот должен быть либо 0, либо 1.
Возвращает:	Возвращает объект, для которого возвращает getattr(dt, 'fold', 0) сложите для всех версий Python. В версиях до Python 3.6, это _DatetimeWithFold объект, который является подкласс datetime.datetime с раз добавлен атрибут, если кратно равно 1.

Новое в версии 2.6.0.

dateutil.tz. datetime_ambiguous ( dt , tz=нет )[источник]

Учитывая дату и время и часовой пояс, определить, является ли данная дата и время неоднозначно (т. е. если есть два времени, различающихся только их DST положение дел).

Параметры:	dt — A datetime. datetime (чей часовой пояс будет игнорироваться, если tz предоставляется.) tz — файл datetime.tzinfo с поддержкой атрибута fold . Если Нет или не указано, будет использоваться собственный часовой пояс даты и времени.
Возвращает:	Возвращает логическое значение независимо от того, является ли «время стены» неоднозначным в тз .

Новое в версии 2.6.0.

dateutil.tz. datetime_exists ( dt , tz=нет )[источник]

Учитывая дату и время и часовой пояс, определить, является ли данная дата и время попал бы в пропасть.

Параметры:	dt — A datetime.datetime (чей часовой пояс будет игнорироваться, если тз предоставляется. ) tz — файл datetime.tzinfo с поддержкой атрибута fold . Если Нет или не указано, будет использоваться собственный часовой пояс даты и времени.
Возвращает:	Возвращает логическое значение независимо от того, существует ли «время стены» в тз .

Новое в версии 2.7.0.

dateutil.tz. resolve_imaginary ( dt )[источник]

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

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

 >>> from dateutil import tz
>>> из даты и времени импортировать дату и время
>>> Нью-Йорк = tz.gettz('Америка/Нью-Йорк')
>>> print(tz. resolve_imaginary(datetime(2017, 3, 12, 2, 30, tzinfo=NYC)))
2017-03-12 03:30:00-04:00
>>> KIR = tz.gettz('Тихий океан/Киритимати')
>>> print(tz.resolve_imaginary(datetime(1995, 1, 1, 12, 30, tzinfo=КИР)))
1995-01-02 12:30:00+14:00
 

В качестве примечания: datetime.astimezone() гарантированно выдает действительный, существующая дата и время, поэтому для получения существующая дата-время, однако это обычно «возвращается» к более раннему времени вместо того, чтобы перейти на сторону STD (хотя никаких гарантий не дается об этом поведении).

Параметры:	dt – A datetime.datetime , который может существовать, а может и не существовать.
Возвраты:	Возвращает существующий datetime.datetime . Если dt не было мнимый, возвращаемый datetime гарантированно будет тем же объектом передается в функцию.

Новое в версии 2.7.0.

Классы

класс dateutil.tz. цуц [источник]

Это объект tzinfo, представляющий часовой пояс UTC.

Примеры:

 >>> из импорта даты и времени *
>>> из импорта dateutil.tz *
>>> datetime.now()
datetime.datetime(2003, 9, 27, 9, 40, 1, 521290)
>>> datetime.now(tzutc())
datetime.datetime(2003, 9, 27, 12, 40, 12, 156379, tzinfo=tzutc())
>>> datetime.now(tzutc()).tzname()
'УНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ'
 

Изменено в версии 2.7.0: tzutc() теперь является одноэлементным, поэтому результат tzutc() будет всегда возвращать один и тот же объект.

 >>> из dateutil.tz импортировать tzutc, UTC
>>> tzutc() — это tzutc()
Истинный
>>> tzutc() — это UTC
Истинный
 

класс dateutil.tz. tzoffset ( имя , смещение )[источник]

Простой класс для представления фиксированного смещения от UTC.

Параметры:	имя – Имя часового пояса, которое будет возвращено, когда Вызывается tzname() . offset — смещение часового пояса в секундах или (начиная с версии 2.6.0, представленное как объект datetime.timedelta ).

класс dateutil.tz. tzlocal [источник]

Подкласс tzinfo , построенный вокруг функций часового пояса time .

класс dateutil.tz. tzwinlocal [источник]

Класс, представляющий информацию о местном часовом поясе в реестре Windows

Хотя dateutil.tz.tzlocal выполняет системные вызовы (через время модуль) для получения информации о часовом поясе, tzwinlocal извлекает правила прямо из реестра Windows и создает объект типа dateutil. tz.tzwin .

Поскольку в Windows нет эквивалента time.tzset() , на Windows, экземпляры dateutil.tz.tzlocal всегда будут отражать настройки часового пояса на момент запуска процесса , что означает изменения настроек часового пояса машины во время выполнения программы в Windows , а не , будет отражаться dateutil.tz.tzlocal . Поскольку tzwinlocal читает реестр напрямую, на него не влияют Эта проблема.

Примечание

Доступно только в Windows

дисплей ()

Вернуть отображаемое имя часового пояса.

переходы ( год )

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

Параметры:	год – Год, переходы которого вы хотите запросить.
Возвраты:	Возвращает кортеж из объектов datetime.datetime , (dston, dstoff) для зон с ежегодным переходом на летнее время или Нет для зон с фиксированным смещением.

класс dateutil.tz. tzrange ( stdabbr , stdoffset=Нет , dstabbr=Нет , dstoffset=Нет , start=Нет , конец=Нет )[источник]

Объект tzrange представляет собой часовой пояс, определяемый набором смещений и сокращения, эквивалентные способу указания переменной TZ в POSIX-подобных системах, но с использованием дельта-объектов Python для указания летнего времени начало, конец и смещения.

Параметры:

stdabbr – сокращение стандартного времени (например, 'EST' ). stdoffset – Целое число или объект datetime.timedelta или эквивалент указание базового смещения от UTC. Если не указано, используется +00:00. dstabbr – Аббревиатура летнего/летнего времени (например, «EDT» ). Если указано, без другой информации о переходе на летнее время предполагается, что наступает летнее время. и поведение по умолчанию или dstoffset , начало и конец использовал. Если не указано и не указана другая информация о переходе на летнее время, предполагается, что в этой зоне нет летнего времени. Если это не указано, а другая информация о переходе на летнее время указана или , Летнее время происходит в зоне, но аббревиатура часового пояса остается без изменений. dstoffset — Целое число или объект datetime.timedelta или эквивалент указание смещения UTC во время летнего времени. Если не указано и любое другое летнее время информация указана, предполагается, что это смещение STD +1 час. начало – A относительнаядельта.относительнаядельта объект или эквивалентное указание время и время года, когда начинается переход на летнее время. К указать, например, что переход на летнее время начинается в 2 часа ночи во 2-е воскресенье в Март, проход: относительная дельта(часы=2, месяц=3, день=1, день недели=ВС(+2)) Если не указано и указана любая другая информация о переходе на летнее время, по умолчанию значение равно 2 часам ночи в первое воскресенье апреля. end — Объект relativedelta.relativedelta или аналогичный представляющие время и время года, когда переход на летнее время заканчивается тем же методом спецификации, что и в начало . Одно примечание что это должно указывать на первый раз в зоне стандарта , поэтому, если переход происходит в 2 часа ночи в зоне летнего времени, и часы переводятся вспять 1 час до 01:00 установите для параметра часа значение +1.

Примеры:

 >>> tzstr('EST5EDT') == tzrange("EST", -18000, "EDT")
Истинный
>>> из импорта dateutil.relativedelta *
>>> range1 = tzrange("EST", -18000, "EDT")
>>> range2 = tzrange("EST", -18000, "EDT", -14400,
... относительная дельта (часы = + 2, месяц = ​​4, день = 1,
...день недели=ВС(+1)),
... относительная дельта (часы = + 1, месяц = ​​10, день = 31,
...день недели=SU(-1)))
>>> tzstr('EST5EDT') == диапазон1 == диапазон2
Истинный
 

класс dateutil.tz. tzstr ( s , posix_offset=False )[источник]

tzstr объекты — это объекты часового пояса, заданные строкой часового пояса как он будет передан в переменную TZ в системах в стиле POSIX (см. Библиотека GNU C: переменная TZ для более подробной информации).

Существует одно заметное исключение, которое заключается в том, что часовые пояса в стиле POSIX используют инвертированный формат смещения, поэтому обычно GMT+3 будет проанализировано как смещение 3 часа позади по Гринвичу. Объект часового пояса tzstr будет анализировать это как смещение на 3 часа вперед по Гринвичу. Если вы хотите поддерживать POSIX поведение, передайте значение True в posix_offset .

Объект tzrange обеспечивает ту же функциональность, но указано с использованием объектов relativedelta.relativedelta . скорее, чем струны.

Параметры:	s – Строка часового пояса в формате переменной TZ . Это может быть байта (2.x: str ), str (2.x: unicode ) или поток, испускающий символы юникода (например, StringIO ). posix_offset — Необязательно. Если установлено значение True , интерпретировать такие строки, как GMT+3 или UTC+3 на 3 часа отстает от UTC, а не опережает его, согласно Стандарт POSIX.

Осторожно

До версии 2.7.0 эта функция также поддерживала часовые пояса в формате:

• EST5EDT,4,0,6,7200,10,0,26,7200,3600
• EST5EDT,4,1,0,7200,10,-1,0,7200,3600

Этот формат является нестандартным и устарел; эта функция вызовет DeprecatedTZFormatWarning до тех пор, пока поддержка удалена в будущей версии.

класс dateutil.tz. циклический ( fileobj )[источник]

Этот объект предназначен для анализа структуры VTIMEZONE в стиле iCalendar. как указано в RFC 5545, раздел 4.6.5, в один или несколько объектов tzinfo .

Параметры:	fileobj — файл или поток в формате iCalendar, который должен быть в кодировке UTF-8 с окончаниями CRLF.

получить ( tzid=None )[источник]

Получить объект datetime.tzinfo по его tzid .

Параметры:	tzid – если доступен ровно один часовой пояс, опуская tzid или передача значения None возвращает его. В противном случае действительный требуется ключ (который можно получить из keys() ).
Поднимает:	ValueError — Вызывается, если tzid не указан, но их больше или менее 1 определенной зоны.
Возвращает:	Возвращает объект datetime.tzinfo , представляющий соответствующий часовой пояс или None , если tzid был не найдено.

ключей ()[источник]

Извлекает доступные часовые пояса в виде списка.

класс dateutil.tz. tzwin ( имя )[источник]

Объект часового пояса, созданный на основе информации о поясе в реестре Windows

Они аналогичны объектам dateutil.tz.tzrange в том, что данные часового пояса предоставляются в формате единого правила смещения за 0 или 2 смены часовых поясов в год.

Параметр:	имя Имя ключа часового пояса Windows, например. «Восточное стандартное время». Полный список ключей можно получить с помощью tzwin.list() .

Примечание

Доступно только в Windows

дисплей ()

Вернуть отображаемое имя часового пояса.

статический список ()

Возвращает список всех часовых поясов, известных системе.

переходы ( год )

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

Параметры:	год – Год, переходы которого вы хотите запросить.
Возвраты:	Возвращает кортеж из объектов datetime.datetime , (dston, dstoff) для зон с ежегодным переходом на летнее время или Нет для зон с фиксированным смещением.

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

Обзор

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

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

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

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

Примечание

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

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

Примечание

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

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

Концепции

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

Объекты 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 в целом безопасно; если вы используя другие часовые пояса, вы должны просмотреть информация о зоне документацию тщательно.

Note

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

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

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

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

К сожалению, во время перехода на летнее время некоторые даты и время не существуют или двусмысленный. Вот почему вы всегда должны создавать осведомленные объекты даты и времени, когда время поддержка зоны включена. (см. Использование раздела ZoneInfo в файле zoneinfo docs для примеров использования атрибута 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() предоставляет набор доступных часовых поясов, которые вы можете использовать для построения карты от вероятных местоположений до часовых поясов.

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

Добавьте следующее промежуточное ПО в СРЕДНЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ :

 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От 0004 до 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 .* получил наивную дату и время",
    Предупреждение,
    r"django\.db\.models\.fields",
)
 

Fixtures

При сериализации осведомленной даты и времени включается смещение 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 для получения инструкций по загрузке определений часовых поясов.

Использование

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.