Пример типового ТЗ

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

1. Название проекта.

    Проектирование, изготовление, монтаж и ввод в эксплуатацию системы поддержания заданного давления воды в трубопроводе на станции второго подъема воды.

2. Заказчик.

    ООО «Хорошая Компания».

3. Исполнитель.

    ООО «ПолюсПлюс».

4. Цель проекта.

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

5. Описание объекта.

    Объект – станция второго подъема воды.

Станция состоит из двух секций по три насоса. Каждая секция запитана от отдельного независимого электрического ввода. Мощность двигателя каждого насоса 75 кВт. Управление двигателями ручное. Все насосы каждой секции работают на одного потребителя. Поддержание заданного давления производится по показаниям манометра вручную при помощи задвижек. При выходе насоса на максимальную производительность к нему параллельно подключается второй насос из другой секции, и так далее по нарастанию.

6. Задание.

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

7. Требуемый алгоритм работы.

    Два шкафа управления насосами на основе частотных преобразователей 75 кВт должны работать одновременно в разных секциях от разных электрических вводов. Каждый шкаф управляет как минимум одним насосом из своей секции.

Минимальное количество одновременно работающих насосов всегда два, по одному из каждой секции. Оба шкафа должны всегда работать на поддержание одного выходного давления воды. В случае пропадания питания на одной из секций функцию поддержания давления берет на себя оставшийся под напряжением шкаф из другой секции. После восстановления питания происходит автоматический ввод в работу отключенного шкафа управления с сохранением всех параметров до отключения. При выходе работающих насосов на максимальную производительность и недостаточном давлении в трубопроводе, необходимо автоматически поочередно параллельно подключать следующий по порядку насос из 1-й секции, затем из противоположной секции и так далее. При выходе 4-х насосов на максимальную производительность необходимо выработать предупреждающий сигнал о возможном порыве трубопровода. При снижении расхода воды (увеличении порогового значения давления) процедуру отключения насосов необходимо осуществлять в обратной последовательности до 2-х оставшихся работающих насосов из противоположных секций. В целях избежания автоколебаний необходимо соблюсти гистерезис при подключении / отключении насосов. В случае возникновения аварийной ситуации необходимо предусмотреть возврат к существующей (ручной) схеме управления. Для оперативного контроля за работой системы предусмотреть внешнее управление и индикацию.

8. Реализация проекта.

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

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

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

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

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

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

Найти релевантных блогеров с качественной аудиторией можно через платформу Getblogger. Работа с блогерами на площадке автоматизирована и не требует обсуждения условий сотрудничества с каждым из них.

Что нужно указать в ТЗ блогера

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

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

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

А вот пункты (могут варьироваться в зависимости от площадки), которые прописывают в техзадании на рекламу:

1. Описание продукта/услуги и цель рекламной кампании.
2. Ссылки на ваши аккаунты в соцсетях, сайт, продукт.
3. Правила произношения названия продукта и бренда.
4. Формат рекламного контента: пост, сторис, видео, Reels.
5. Требования к визуальной составляющей – за основу берут требования брендбука.
6. Объем текста при необходимости. Число отметок/ссылок в тексте.
7. Основные триггеры, тезисы, четкий месседж для целевой аудитории. Должно быть четкое понимание выгоды и причины для покупки, и вы должны сперва их объяснить самому блогеру.
8. Сроки и дата выхода рекламы, штрафы и неустойки при нарушении условий сотрудничества.

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

Пример ТЗ для сторис в Инстаграме* + памятка

Если мы даем рекламу в сторис, важно понимать, что Истории длятся до 15 сек. Не стоит писать много текста, чтобы блогер не тараторил. 15 секунд – это примерно 300 символов. Обычно блогеры предлагают размещение в формате 2-3-4 сторис подряд. Поэтому ТЗ для сторис строится по такой схеме:

Сториз 1 – заходим через проблему, интерес или интригу + опрос.

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

Сториз 2 – даем решение.

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

Сториз 3 – направляем на развернутое решение.

3 сторис обычно ссылается на лид-магнит с внешней ссылкой на сайт или ваш аккаунт.

Пример ТЗ для рекламы в сторис личного блога модели в Инстаграме*

Памятка для ТЗ по сторис:

1. Часть важного или самое главное – предлагаем вынести в текст. И обязательно подписываем, что есть что. В то же время не нужно слишком много текста. Мелкий текст будет тяжело прочитать за 15 секунд, тем более если его много.
2. Максимально естественно будет говорить на языке целевой аудитории. Даже если ваш аккаунт в смежной нише ведется в другом стиле, найдите компромиссное решение.
3. В тексте через @ указываем ссылку на наш профиль, если требуется.
4. Эмодзи и гифки помогут сократить текст и сделать его более живым и привлекательным.
5. Дублируйте аудиоряд подписями – часть пользователей не включает звук в сторис.
6. Делайте текст привлекательным, легким для чтения – в сторис не ищут глубокого контента. Истории – это в первую очередь эмоции, обратная связь и геймификация.
7. Прежде чем отправлять текст блогеру, прочитайте его выразительно вслух. Это поможет выявить слабые места и проверить, успеет ли блогер прочитать все, что вы написали.

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

Читайте также: Как найти блогеров для рекламы в Инстаграме*: 8 способов.

Пример ТЗ для поста в Инстаграме* + памятка

Крутой прием в рекламных постах у блогеров, который всегда хорошо работает, – розыгрыш через сторителлинг. Я часто пишу пост под тематику приза.

Структура рекламного поста у блогера со сторителлингом и розыгрышем:

1. Вводный абзац, который сразу вовлекает в историю.
2. С какими проблемами сталкивается блогер.
3. Где нашел/нашла решение.
4. Почему доверяет бренду.
5. Чем интересен предмет, который будем разыгрывать.
6. Где можно купить предмет, который будем разыгрывать.
7. Хорошая новость – сегодня его можно выиграть или получить бесплатно.
8. Условия розыгрыша.
9. Призыв выполнить условия.

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

Пример совместного розыгрыша известного книжного издательства Clever и бренда «Атлас»

Памятка по ТЗ для постов:

1. Начать нужно с анализа блогера и событий, которые происходят в его жизни сейчас.
2. Хорошо, если текст начинается созвучно прошлым темам публикаций.
3. Обычно упоминание делают через @ в двух местах – в начале поста и внизу.
4. Иногда вместо заключения можно сделать розыгрыш, но предварительно стоит это уточнить.
5. Иногда можно попросить сделать галерею фото в посте. Например, разместить после личного фото отзывы наших клиентов.
6. Помните, что формат сторителлинга заходит лучше, чем прямая реклама. Будет здорово, если сначала пользователи прочитают историю.

Читайте также: Как подготовить рекламную интеграцию у Инстаграм*-блогера.

Пример ТЗ для видеомонтажа

Если вы смотрите YouTube, то видите, как часто стали выходить специальные рекламные интеграции у блогеров. Например, бренды доверяют ребятам из ЧБД снимать рекламные ролики на разных условиях, и мы видим совершенно прекрасные рекламные видосы с отсылками к разным фильмам. Или Азамат Мусагалиев в шоу «Я себя знаю» также снимает юморную рекламу по собственным сценариям. Конечно, предварительно они согласуют их с заказчиком, и наверняка имеются и стандартные ТЗ для съемки.

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

Стандартное ТЗ на видеомонтаж в виде чек-листа

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

Иногда вам кажется, что вы сделали все как написано в статье – благо их в интернете достаточно, но реклама у блогеров не работает?

Есть типичные ошибки при создании ТЗ:

• Пользователям предлагают сделать непонятные действия (ТЗ для розыгрышей).
• Не расставлены акценты в видео/тексте. Внимание человека разбегается, он не понимает, на что смотреть.
• Непонятный текст: водянистый, неоправданно длинный, «вокруг да около», обобщающие конструкций, нет конкретики.
• Голословные утверждения или субъективные мнения. Каждое утверждение должно быть подкреплено доказательством.

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

Читайте также: Сотрудничество с блогерами: плюсы, минусы, подводные камни.

Как проверить материал ТЗ перед отправкой блогеру

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

• Какую эмоцию вызывает заголовок?
• Дает ли понятное, с точки зрения целевой аудитории, объяснение?
• Не перегружен ли текст/видеоряд?
• Реализована ли логика, для которой создавался контент?
• Производит ли контент трансформацию внутри по мере прочтения/просмотра?

Выпишите ответы, проанализируйте и внесите изменения в рекламный текст.

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

Здесь приведу еще несколько советов по рекламным интеграциям:

1. Ваш ролик/текст построен так, что удерживает внимание человека – каждая секунда удержанного активного внимания важна.
2. Используйте контрасты, изображения и образы людей, юмор для привлечения внимания.
3. Используйте эмоционально заряженные слова.
4. Рекламный текст производит трансформацию, дает инсайты – переводит человека из состояния пассивного наблюдателя в вовлеченного.
5. Рекламный текст/ролик содержит явную ценность и вызывает позитивные эмоции, есть доказательства: понятные факты, ссылки.

Анализ эффективности рекламного размещения

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

Как проверять Инстаграм*-блогеров перед покупкой рекламы, мы уже писали.

А как замерять эффективность?

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

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

Для Инстаграма* я делаю это так:

Перед рекламой у блогера сохраняю отчет об аудитории (гео, возраст и т. д.):

Статистика аудитории аккаунта в Инстаграме* в шаблоне Google Data Studio от DataFan

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

Желаю удачи в продвижении, высоких вам конверсии и адекватных блогеров!

Карта часовых поясов TZ США

Карта часовых поясов TZ США

Шейп-файл часовых поясов TZ США

Эта карта больше не поддерживается.

Карта на основе OSM доступна по адресу
https://github.com/evansiroky/timezone-boundary-builder.

Последнее обновление данных: 5 июля 2013 г.

Последнее обновление страницы: 20 марта 2016 г.

ТЗ версия: 2016d

Шейп-файл tz_us (zip, sha1) фиксирует границы часовых поясов TZ США.

Геометрия полностью получена из шейп-файлов countyp020p и timeznp020, предоставленных Национальным атласом.

Представлены все часовые пояса США, указанные в TZ zone.tab, за исключением America/Shiprock , который включен в America/Denver .

Снимок шейп-файла

Это снимок шейп-файла.

 

Известные проблемы

TZ упоминает, что America/Kentucky/Louisville содержит три округа Индиана и часть Кентукки, но не описывает именно эту часть Кентукки. На карте это округ Джефферсон.

В общем, города на границе зоны или рядом с ней могут практически следовать по времени соседней зоны. Мы не пытаемся зафиксировать границы на таком уровне детализации. Например, граница между America/Los_Angeles и Америка/Денвер следует за границей Невады/Юты; на практике и по закону с 1999 года город Уэст-Вендовер, штат Невада, является частью America/Denver .

 

Логическое описание зон

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

• Восток: Америка/Нью-Йорк
• Центральный: Америка/Чикаго
• Гора: Америка/Денвер
• Тихоокеанский регион: Америка/Лос-Анджелес

Аляска

• Америка/Адак: Аляска, с timeznp020.symbol = HA
• Америка/Якутат: г. Якутат и р-н
• Америка/Джуно: Зона переписи населения Скагуэй-Хуна-Ангун, город и округ Джуно, округ Хейнс
• Америка/Ситка: Район переписи населения Врангель-Петербург, город и район Ситка, район Кетчикан-Гейтуэй, неустановленный район на юге Кетчикана, граничащий с Канадой, Принц Уэльский-Внешний Кетчикан. Район переписи населения за вычетом Метлакатлы
• Америка/Метлакатла: резервация Метлакатла, охватывающая весь остров Аннет, а также несколько близлежащих островов
• Америка/Анкроридж: остальная часть Аляски, к востоку от 162°
• Америка/Номер: остальная часть Аляски, к западу от 162°

Аризона

• Америка/Феникс: Аризона, за исключением земель навахо

Гавайи

• Америка/Гонолулу

Айдахо

• Америка/Бойсе: часть штата Айдахо, легально находящаяся в горной зоне

Индиана

• Америка/Индиана/Маренго: округ Кроуфорд
• Америка/Индиана/Винсеннес: округа Дэвис, Дюбуа, Нокс и Мартин
• Америка/Индиана/Tell_City: округ Перри
• Америка/Индиана/Петербург: Округ Пайк
• Америка/Индиана/Нокс: округ Старке
• Америка/Индиана/Винамак: округ Пуласки
• Америка/Индиана/Веве: округ Швейцария
• Америка/Кентукки/Луисвилл: округа Кларк, Флойд и Харрисон.
• Америка/Нью-Йорк: округа Дирборн и Огайо
• Америка/Чикаго: округа Гибсон, Джаспер, Лейк, ЛаПорт, Ньютон, Портер, Поузи, Спенсер, Вандербург и Уоррик
• Америка/Индиана/Индианаполис: остальная часть Индианы

Кентукки

• Америка/Кентукки/Луисвилл: округ Джефферсон.
• Америка/Кентукки/Монтиселло: округ Уэйн

Мичиган

• Америка/Меномини: округа Дикинсон, Гогебич, Айрон и Меномини

Северная Дакота

• Америка/Северная Дакота/Центр: Северная Дакота: округ Оливер
• Америка/Северная Дакота/Нью-Салем: Северная Дакота: округ Мортон
• Америка/Северная Дакота/Бьюла: Северная Дакота: округ Мерсер

Орегон

• Америка/Бойсе: часть штата Орегон, легально находящаяся в горной зоне

Пуэрто-Рико

• Америка/Пуэрто-Рико

Виргинские острова

• Америка/Сент-Томас

 

Создание шейп-файла

Ингредиенты (zip, sha1) содержат скрипт для сборки карты, модифицированные исходники.

Отправной точкой является несколько слоев карты из Национального атласа:

• слой «Границы округа, 2001» (описание, шейп-файл)
• слой «Часовые пояса» (описание, шейп-файл). Этот карты фиксируют только текущие часовые пояса и не включают исторические часовые пояса, записанные в TZ

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

Следующим шагом является наложение двух карт, постепенное присвоение tzid геометрии (обозначаемой комбинацией штата, округа и «современного» часового пояса в соответствии с приведенным выше описанием) и, наконец, растворение на атрибут tzid. Точные детали заданий смотрите в сценарии в ингредиентах.

---

Условия использования

Насколько это возможно по закону, Эрик Мюллер отказался от всех авторских и смежных или смежных прав на карты efele.net/tz (включая шейп-файлы, веб-страницы с их описанием, сценарии и данные, использованные для их создания). Эта работа опубликована в Соединенных Штатах Америки.

Обратите внимание, что это не влияет на права других пользователей. Я не уполномочен определять, существуют ли такие права.

---

Контакт — Спасибо

История:

• 20 марта 2016 г.:
  • добавлен SHA-1 для zip-файлов.
• 5 июля 2013 г.:
  • некоторые Алеутские острова были неправильно указаны в Америке/Адаке, а не в Америке/Номе. Спасибо Эрику Мичиелли за сообщение о проблеме.
• 30 сентября 2012 г.:
  • расширил Америку / Метлакатлу, чтобы охватить весь остров Аннет и несколько близлежащих островов. Спасибо Джеймсу Дибелю за указание на эту проблему.
• 25 июня 2012 г., обновлено для TZ 2012c:
  • добавлены Америка/Ситка и Америка/Метлакатла.
  • устранил небольшую проблему, спасибо Дэну О’Нилу
• 7 февраля 2011 г.:
  • добавлены Америка/Северная Дакота/Беула
  • исправления полигонов Америки/Виннипега, спасибо Veeder South
• 13 марта 2010 г .:
  • обновлено до TZ 2010e (без изменения данных)
• 14 ноября 2009 г .:
  • Аляска теперь обрабатывается должным образом, благодаря информации, предоставленной Оскаром ван Влейменом
  • Округ Джефферсон, штат Кентукки, теперь находится в Америке/Кентукки/Луисвилле
  • добавлено логическое описание зон
• 10.11.2009: обновлено для ТЗ 2009р; добавлены условия использования.
• 5 ноября 2008 г . : примечание о Вест-Вендовере, штат Невада, спасибо Вернону Коулу
.
• 13 сентября 2008 г.: добавлен снимок
.
• 2008: первая версия

 

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 не передается аргумент или пустая строка 903:31, местное время возвращается:

 >>> получить()
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), местоположение a tzfile(5) файл zoneinfo или TZ переменный часовой пояс спецификатор. Пустая строка, без аргумента или Нет интерпретируется как местное время.
Возвраты:	Возвращает экземпляр одного из dateutil tzinfo подклассы.

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

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

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

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

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

classmethod gettz. cache_clear ()

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

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

Параметры:	fold — значение атрибута fold в возвращаемом datetime. Этот должен быть либо 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

дисплей ()

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

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

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

Параметры:	год – Год, переходы которого вы хотите запросить.
Возвраты:	Возвращает кортеж из объектов 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 используют инвертированный формат смещения, поэтому обычно 903:30 GMT+3 будет проанализировано как смещение На 3 часа отстает от по Гринвичу. Объект часового пояса tzstr будет анализировать это как смещение на 3 часа впереди по Гринвичу. Если вы хотите поддерживать POSIX поведение, передайте значение True в posix_offset .

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

Параметры:	s – Строка часового пояса в формате переменной TZ . Это может быть байт (2.x: стр ), стр (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=нет )[источник]

Получить объект 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

дисплей ()

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

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

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