Что такое Дата и Время на компьютере, и каким образом их можно настроить? Теперь мы рассмотрим еще одну полезную панельку – это дата и время. Любой файл, который вы создаете или изменяете, привязан к дате и времени. Если вы кликните правой кнопкой мыши по файлу, и выберите в выпадающем меню ссылку «Свойства», то увидите на вкладке «Общие» дату создания, изменения и открытия файла. Каким образом компьютер знает, сколько сейчас времени и какой день календаря? Всё очень просто!
Как компьютер знает текущую дату и время?
Во всех компьютерах есть маленькая батарейка, которая обычно размещена на материнской плате. Вот эта батарейка в 3 вольта, и не дает компьютеру забывать текущую дату и время.
Даже когда компьютер выключен, батарейка питает ПЗУ (Постоянное Запоминающее Устройство), в котором хранятся все текущие настройки нашего компьютера.
Вот когда эта батарейка выходит из строя, то на компьютере постоянно сбивается дата и время. А иногда он и вовсе не может загрузиться, пока вы не выставите правильную дату в его начальных загрузках – BIOS (Basic Input/Output System – Базовая система ввода/вывода), записанного в ПЗУ материнской платы) . Это значит, что пора батарейку . Но вы не волнуйтесь! Обычно заряда батарейки хватает на 4-5 лет.
Как настроить Дату и время на компьютере
Иногда бывает необходимость изменить дату или время на компьютере, или отключить автоматическую смену времени с летнего на зимний период. В этом случае нам надо попасть в настройки даты и времени.
В Windows 10 дату и время можно настроить следующим образом:
Нажав на кнопку «Изменить дату и время » на вкладке «Дата и время », вы можете изменить настройки текущего времени.
Практически все проекты сталкиваются с проблемами, вызванными неправильной обработкой и хранением даты и времени. Даже если проект используется в одном часовом поясе, все равно после перехода на зимнее/летнее время можно получить неприятные неожиданности. При этом мало кто озадачивается реализацией правильного механизма со старта, потому что кажется, что с этим проблем быть не может, так как все тривиально. К сожалению, в последствии реальность показывает, что это не так.
Логически можно выделить следующие типы значений, относящиеся к дате и времени:
Рассмотрим каждый пункт по отдельности, не забывая об .
Дата и время
Допустим, лаборатория, которая собрала материал для анализа находится в часовом поясе +2, а центральный филиал, в котором следят за своевременным выполнением анализов — в поясе +1. Время, приведенное в примере, было отмечено при сборе материала первой лабораторией. Возникает вопрос — какую цифру времени должен увидеть центральный офис? Очевидно, что программное обеспечение центрального офиса должно показывать 15 января 2014 года 12:17:15 — на час меньше, так как по их часам событие произошло именно в этот момент.Рассмотрим одну из возможных цепочек действий, через которую проходят данные с клиента на сервер и обратно, позволяющую всегда корректно отображать дату/время согласно текущему часовому поясу клиента:
- Значение создается на клиенте, например, 2 марта 2016 15 :13:36, клиент находится в часовом поясе +2.
- Значение преобразуется в строковое представление для передачи на сервер — “2016-03-02T15 :13:36+02:00”.
- Сериализованные данные передаются на сервер.
- Сервер десериализует время в объект даты/времени, приводя его при этом к своему текущему часовому поясу. Например, если сервер работает в +1, значит объект будет содержать 2 марта 2016 14 :13:36.
- Сервер сохраняет данные в базу, при этом она не содержит никакой информации о часовом поясе — наиболее часто используемые типы даты/времени просто о нем ничего не знают. Таким образом, в базу будет сохранено 2 марта 2016 14 :13:36 в «неизвестном» часовом поясе.
- Сервер читает данные из базы и создает соответствующий объект со значением 2 марта 2016 14 :13:36. И так как сервер работает в часовом поясе +1, то и это значение будет трактоваться в рамках того же часового пояса.
- Значение преобразуется в строковое представление для передачи на клиент — “2016-03-02T14 :13:36+01:00”.
- Сериализованные данные отправляются на клиент.
- Клиент десериализует полученное значение в объект даты/времени, приводя его при этом к своему текущему часовому поясу. Например, если это -5, то отображаемое значение должно быть равно 2 марта 2016 09 :13:36.
- Время на клиенте может быть сформировано вообще без часового пояса — например, DateTime тип в.NET с DateTimeKind.Unspecified.
- Механизм сериализации может использовать формат, который не включает в себя смещение часового пояса.
- При десериализации в объект может игнорироваться смещение часового пояса, особенно в «самодельных» десериализаторах — как на сервере, так и на клиенте.
- При чтении из базы объект даты/времени может быть сформирован вообще без часового пояса — например, DateTime тип в.NET с DateTimeKind.Unspecified. Более того, с DateTime в.NET на практике именно так и получается, если сразу после вычитки явно не указывать другой DateTimeKind.
- Если сервера приложения, работающие с общей базой данных, находятся в разных часовых поясах — будет серьезная путаница в смещениях во времени. Значение даты/времени, записанное в базу сервером А и прочитанное сервером Б будет заметно отличаться от того же исходного значения, записанного сервером Б и прочитанного сервером А.
- Перевод серверов приложения из одного пояса в другой приведет к неправильной трактовке уже сохраненных значений даты/времени.
Правила перевода на летнее/зимнее время — вещь, строго говоря, переменная. Разные страны могут иногда менять свои правила, и эти изменения должны быть заблаговременно заложены в обновления системы. На практике неоднократно встречались ситуации некорректной работы этого механизма, которые по итогу решались установкой хотфиксов либо операционной системы, либо используемых сторонних библиотек. Вероятность повторения тех же проблем — не нулевая, поэтому лучше иметь способ гарантированно их избежать.
Учитывая описанные выше соображения, сформулируем как можно более надежный и простой подход к передаче и хранению времени: на сервере и в базе данных все значения должны быть приведены к часовому поясу UTC .
Рассмотрим, что нам дает такое правило:
- При отправке данных на сервер клиент должен передать смещение часового пояса, чтобы сервер мог корректно преобразовать время в UTC. Альтернативный вариант — обязать клиент делать это преобразование, но первый вариант гибче. При получении данных обратно с сервера клиент будет переводить дату и и время в свой локальный часовой пояс зная, что ему в любом случае придет время в UTC.
- В UTC нет переходов на летнее и зимнее время, соответственно связанные с этим проблемы будут неактуальны.
- На сервере при чтении из базы не нужно преобразовывать значения времени, достаточно только явно указывать, что оно соответствует UTC. В.NET, например, этого можно достичь установкой DateTimeKind для объекта времени в DateTimeKind.Utc.
- Разница часовых поясов между серверами, работающими с общей базой данных, как и перевод серверов из одного пояса в другой, никак не отразятся на корректности получаемых данных.
- Сделать механизм сериализации и десериализации такой, чтобы значения даты/времени корректно переводились из UTC в локальный часовой пояс и обратно.
- Убедиться, что десериализатор на стороне сервера создает объекты даты/времени в UTC.
- Сделать так, чтобы при вычитке из базы объекты даты/времени создавались в UTC. Этот пункт иногда обеспечивают без изменений кода — просто системный часовой пояс на всех серверах устанавливается в UTC.
- В требованиях к системе нет надобности отображать локальное время и/или смещение часового пояса именно в том виде, в котором оно было сохранено. Например, в авиабилетах время вылета и прибытия должно быть распечатано в часовом поясе, соответствующем расположению аэропорта. Или если сервер отправляет на печать инвойсы, созданные в разных странах, на каждом должно в итоге стоять локальное время, а не преобразованное в часовой пояс сервера.
- Все значения даты и времени в системе являются «абсолютными» — т.е. описывают момент времени в будущем или прошлом, которому соответствует единственное значение в UTC. Например, «пуск ракеты-носителя состоялся в 23:00 по киевскому времени», или «совещание будет идти с 13:30 до 14:30 по минскому времени». В разных часовых поясах цифры для этих событий будут разные, но они будут описывать один и тот же момент времени. Но может так случиться, что требования к программному обеспечению подразумевают «относительное» локальное время для некоторых случаев. Например, «эта передача на телевидении будет идти с 9:00 до 10:00 утра в каждой стране, где есть филиал телеканала». Получается, что показ передачи — это не одно событие, а несколько, причем потенциально все они могут происходить в разные отрезки времени по «абсолютной» шкале.
| .NET | DateTimeOffset |
| Java | org.joda.time.DateTime, java.time.ZonedDateTime |
| MS SQL | datetimeoffset |
| Oracle, PostgreSQL | TIMESTAMP WITH TIME ZONE |
| MySQL | — |
Нарушение второго условия — более сложный случай. Если это «относительное» время нужно хранить просто для отображения, и нет задачи определить «абсолютный» момент времени, когда событие наступило или наступит для заданного часового пояса — достаточно просто запретить преобразование времени. Например, пользователь ввел начало передачи для всех филиалов телекомпании 25 марта 2016 года в 9:00, и оно в таком виде будет передаваться, храниться и отображаться. Но может случиться, что какой-то планировщик должен автоматически выполнить специальные действия за час до начала каждой передачи (разослать уведомления или проверить наличие каких-то данных в базе телекомпании). Надежная реализация такого планировщика является нетривиальной задачей. Допустим, планировщик осведомлен о том, в каком часовом поясе находится каждый из филиалов. И одна из стран, где есть филиал, через некоторое время решает сменить часовой пояс. Случай не настолько редкий, как может показаться — за этот и два предыдущих года я насчитал больше 10 подобных событий (http://www.timeanddate.com/news/time/). Получается, что либо пользователи должны поддерживать привязки к часовым поясам в актуальном состоянии, либо планировщик должен в автоматизированном режиме брать эту информацию из глобальных источников типа Google Maps Time Zone API. Я не берусь предложить универсальное решение для подобных случаев, просто отмечу, что такие ситуации требуют серьезной проработки.
Как видно из вышесказанного, не существует единого подхода, покрывающего 100% случаев . Поэтому сперва нужно четко понять из требований, какие из упомянутых выше ситуаций будут в вашей системе. С большой вероятностью, все ограничится первым предложенным подходом с хранением в UTC. Ну а описанные исключительные ситуации его не отменяют, а просто добавляют другие решения для частных случаев.
Дата без времени
Допустим, с правильным отображением даты и времени с учетом часового пояса клиента разобрались. Перейдем к датам без времени и примеру, указанному для этого случая в начале — «новый контракт вступает в силу 2 февраля 2016 года». Что будет, если для таких значений использовать те же типы и тот же механизм, что и для «обычных» даты с временем?Не во всех платформах, языках и СУБД есть типы, хранящие только дату. Например, в.NET есть только тип DateTime, отдельного «просто Date» нет. Даже если при создании такого объекта была указана только дата, время все равно присутствует, и оно равно 00:00:00. Если мы значение «2 февраля 2016 00:00:00» из пояса со смещением +2 переведем в +1, то получим «1 февраля 2016 23:00:00». Для указанного выше примера это будет равносильно тому, что в одном часовом поясе новый контракт начнет действовать 2 февраля, а в другом — 1 февраля. С юридической точки зрения это абсурд и так, конечно же, быть не должно. Общее правило для «чисто» дат предельно простое — такие значения не должны преобразовываться ни на одном шаге сохранения и чтения.
Есть несколько способов избежать преобразование для дат:
- Если платформа поддерживает тип, представляющий дату без времени, то его и нужно использовать.
- Добавлять в метаданные объектов специальный признак, который будет говорить сериализатору, что для данного значения часовой пояс нужно игнорировать.
- Передавать дату с клиента и обратно как строку, а хранить как дату. Такой подход неудобен, если на клиенте дату нужно не только отображать, но еще и производить какие-то операции над ней: сравнение, вычитание и т.д.
- Передавать и хранить как строку, а преобразовывать в дату только для форматирования с учетом региональных настроек клиента. Имеет еще больше недостатков чем предыдущий вариант — например, если в хранимой строке части даты идут не в порядке «год, месяц, день», то будет невозможно сделать эффективный индексированный поиск по диапазону дат.
Временной интервал
С хранением и обработкой временных интервалов все просто: их величина не зависит от часового пояса, поэтому никаких особых рекомендаций здесь нет. Их можно хранить и передавать как количество единиц времени (целое или с плавающей точкой, в зависимости от необходимой точности). Если важна секундная точность — то как количество секунд, если миллисекундная — то как количество миллисекунд и т.д.А вот вычисление интервала может иметь подводные камни. Предположим, у нас есть типовой код на C#, который считает интервал времени между двумя событиями:
DateTime start = DateTime.Now;
//...
DateTime end = DateTime.Now;
double hours = (end - start).TotalHours;
На первый взгляд, никаких проблем здесь нет, но это не так. Во-первых, могут возникнуть проблемы с юнит-тестированием такого кода, но об этом мы поговорим чуть позже. Во-вторых, давайте представим, что начальный момент времени пришелся на зимнее время, а конечный — на летнее (например, таким образом замеряется количество рабочих часов, а у работников есть ночная смена).
Предположим, код работает в часовом поясе, в котором переход на летнее время в 2016 году происходит в ночь 27 марта, и смоделируем описанную выше ситуацию:
DateTime start = DateTime.Parse("2016-03-26T20:00:15+02");
DateTime end = DateTime.Parse("2016-03-27T05:00:15+03");
double hours = (end - start).TotalHours;
Этот код даст в результате 9 часов, хотя фактически между этими моментами прошло 8 часов. В этом легко убедиться, изменив код вот таким образом:
DateTime start = DateTime.Parse("2016-03-26T20:00:15+02").ToUniversalTime();
DateTime end = DateTime.Parse("2016-03-27T05:00:15+03").ToUniversalTime();
double hours = (end - start).TotalHours;
Отсюда вывод — любые арифметические операции с датой и временем нужно делать, используя либо UTC значения, либо типы, хранящие информацию о часовом поясе
. А потом обратно переводить в локальные в случае надобности. С этой точки зрения, изначальный пример легко исправить, поменяв DateTime.Now на DateTime.UtcNow.
Этот нюанс не зависит от конкретной платформы или языка. Вот аналогичный код на Java, имеющий тот же недостаток:
LocalDateTime start = LocalDateTime.now();
//...
LocalDateTime end = LocalDateTime.now();
long hours = ChronoUnit.HOURS.between(start, end);
Исправляется он также легко — например, использованием ZonedDateTime вместо LocalDateTime.
Расписание запланированных событий
Расписание запланированных событий – более сложная ситуация. Универсального типа, позволяющего хранить расписания, в стандартных библиотеках нет. Но такая задача возникает не так уж редко, поэтому готовые решения можно найти без проблем. Хорошим примером является формат планировщика cron, который в том или ином виде используется другими решениями, например, Quartz: http://quartz-scheduler.org/api/2.2.0/org/quartz/CronExpression.html . Он покрывает практически все нужды составления расписаний, включая варианты типа «вторая пятница месяца».В большинстве случаев писать свой планировщик не имеет смысла, так как существуют гибкие проверенные временем решения, но если по какой-то причине есть надобность в создании своего механизма, то как минимум формат расписания можно позаимствовать у cron.
Помимо описанных выше рекомендаций, посвященных хранению и обработке разнотипных значений времени, есть еще несколько других, о которых тоже хотелось бы сказать.Во-первых, по поводу использования статических членов класса для получения текущего времени — DateTime.UtcNow, ZonedDateTime.now() и т.д. Как и было сказано, использование их напрямую в коде может серьезно усложнить юнит-тестирование, так как без специальных мок фреймворков подменить текущее время не получится. Поэтому, если вы планируете писать юнит тесты, следует позаботиться о том, чтобы реализацию таких методов можно было подменить. Для решения этой задачи есть как минимум два способа:
- Выделить интерфейс IDateTimeProvider с единственным методом, возвращающим текущее время. Затем добавить зависимость на этот интерфейс во всех единицах кода, где нужно получать текущее время. При обычном выполнении программы во все эти места будет инжектиться реализация «по умолчанию», которая возвращает реальное текущее время, а в юнит тестах – любая другая необходимая реализация. Такой способ является наиболее гибким с точки зрения тестирования.
- Сделать свой статический класс с методом для получения текущего времени и возможностью установить любую реализацию этого метода извне. Например, в случае C# кода этот класс может выставлять наружу свойство UtcNow и метод SetImplementation(Func
impl). Использование статического свойства или метода для получения текущего времени избавляет от надобности везде явно прописывать зависимость от дополнительного интерфейса, но с точки зрения принципов ООП не является идеальным решением. Однако, если по каким-то соображениям предыдущий вариант не подходит, то можно воспользоваться этим.
Второй нюанс с получением текущего времени — это то, что клиенту доверять нельзя . Текущее время на компьютерах пользователей может очень сильно отличаться от реального, и если есть логика, завязанная на него, то эта разница может все испортить. Все места, где есть необходимость получать текущее время, должны по возможности выполняться на стороне сервера. И, как уже было сказано ранее, все арифметические операции с временем должны производиться либо в UTC значениях, либо с использованием типов, хранящих смещение часового пояса.
И еще одна вещь, которую хотелось упомянуть — это стандарт ISO 8601 , описывающий формат даты и времени для обмена информацией. В частности, строковое представление даты и времени, используемое при сериализации, должно соответствовать этому стандарту для предотвращения потенциальных проблем с совместимостью. На практике крайне редко приходится самому реализовывать форматирование, поэтому сам стандарт может быть полезен в основном в ознакомительных целях.
Теги: Добавить метки
Проблемы с работой часов на компьютере могут быть вызваны неполадками в аппаратном или программном обеспечении или некорректной работой драйверов.
Ниже приведены возможные ошибки, их признаки и способы их устранения.
Примечание.Для устранения проблем, связанных с работой часов на компьютере, может потребоваться перезагрузка компьютера или мониторинг часов на предмет повторения ошибок. HP рекомендует распечатать этот документ для дальнейшего использования.
Настройки часов на компьютере сбрасываются
Если время в Windows не соответствует текущему или часто требуется переустановка времени, проделайте следующие шаги.
Шаг 1. Включение и выключение настроек времени Интернет
Для некоторых компьютеров возможна настройка синхронизации часов на компьютере с сервером времени в Интернет, когда компьютер подключается к сети Интернет. Синхронизация часов на компьютере с временем Интернет обычно рекомендуется как наиболее точный метод поддержания актуального значения времени. В ряде случаев подключение к серверу времени Интернет может привести к тому, что часы на компьютере будут показывать неправильное время.
Чтобы убедиться, что выбран правильный часовой пояс, и для изменения настроек времени Интернет, выполните следующие действия.
Шаг 2. Обновление BIOS
Если для вашего компьютера доступно обновление BIOS, его применение может устранить проблемы неправильного отображения времени на часх вашего компьютера. Инструкции по поиску и обновлению BIOS см. в документе технической поддержки HP Обновление BIOS Обновление BIOS для ноутбуков.
После обновления BIOS понаблюдайте за часами, не повторяется ли проблема. Если часы показывают правильное время, проблема решена. В противном случае переходите к Шагу 3: удаление и переустановка часов реального времени для решения проблемы.
Шаг 3. Удаление и переустановка часов реального времени в Windows 8
Если часы вашего компьютера показывают неправильное время, попробуйте удалить и переустановить часы реального времени, переведя перед этим систему в безопасный режим. Для этого выполните следующие действия:
Внимание!Не пытайтесь переустановить часы реального времени в обычном режиме загрузки. Это может привести к сбою в системе.
Код ошибки: Не заданы время и дата
Часы в настольных компьютерах работают от батарейки аналогично наручным часам с питанием от аккумулятора. Такая внутренняя батарейка называется батарея CMOS или батарея часов реального времени. С помощью этой батареи поддерживается актуальное значение времени, когда компьютер выключен. Как и в наручных часах, батарейку необходимо заменить, если уровень заряда упал до низкого значения.
Если при запуске компьютера отображается сообщение об ошибке Не заданы время и дата , то возможно необходимо заменить батарею CMOS или часов реального времени. Нижеприведенные ссылки и указания помогут найти информацию, как заменить CMOS или часы реального времени на компьютере в зависимости от его типа.
- Для компьютеров HP TouchSmart, моноблоков (AiO) и ноутбуков выполните следующие действия.
Введите в поле поиска на верху страниц наименование серии компьютера и таймер реального времени в поле поиска и нажмите клавишу ввода .
Например, введите HP Envy 15-3000 таймер реального времени для поиска документов, описывающих проблемы с часами реального времени для компьютеров серии HP Envy 15-3000.
Внимание!
Не пытайтесь заменить батарею, если вам не удалось найти документ, описывающей, как заменить батарею CMOS или часов реального времени на вашем типе компьютера. Для устранения неисправности обратитесь в авторизованный сервис-центр.
Для замены батареи CMOS или часов реального времени следуйте приведенным в документе инструкциям.
Для настольных компьютеров (в вертикальном корпусе) перейдите к документу Удаление и замена батареи CMOS и следуйте приведенным в нем инструкциям по замене батареи CMOS.
Системные часы показывают неправильное время после выхода из режима гибернации
После выхода из режима гибернации на некоторых компьютерах системные часы могут останавливаться или сбрасывать значение. Для устранения неполадки попробуйте выполнить следующие действия. Инструкции по поиску и обновлению BIOS см. в документе технической поддержки HP Обновление BIOS для настольных компьютеров или Обновление BIOS для ноутбуков.
Используя параметр "expires" в тегах и URL IBM® Web Content Manager , можно указать срок хранения данных в кэше. После того, как данные в кэше устаревают, при следующем их запросе они извлекаются с сервера. Параметр срока хранения не является обязательным.
Настраиваемые параметры срока хранения в кэше можно использовать только когда кэш веб-материалов по умолчанию сервера настроен на расширенное кэширование или отключен. Если по умолчанию используется Обычное кэширование содержимого веб-страниц, то настраиваемое истечение срока хранения применяться не может. Хотя параметры настраиваемых сроков хранения нельзя применять при включенном Обычном кэшировании, их можно применять при включенном Расширенном кэшировании для определения сроков хранения данных в Обычном кэше.
Значениями параметра срока хранения могут быть либо относительный период, либо абсолютное значение даты и времени. Обычное кэширование
- EXPIRES="ABS {дата и время}"
- EXPIRES="REL {целое значение}{единицы}"
- CONTENTCACHEEXPIRES="ABS {дата и время}"
- CONTENTCACHEEXPIRES="REL {целое значение}{единицы}"
- CONNECTORCACHEEXPIRES="ABS {дата и время}"
- CONNECTORCACHEEXPIRES="REL {целое значение}{единицы}"
Примеры:
Стратегии настраиваемого срока хранения
- Указывая настраиваемые параметры сроков хранения при извлечении внешних данных с помощью тега connect или запроса URL, следует использовать CONNECTORCACHEEXPIRY=.
- Если по умолчанию используется обычный кэш, или если указан CACHE= в теге connect или запросе URL, следует использовать EXPIRES=
- Если по умолчанию используется расширенный кэш, или если указан CONTENTCACHE= в теге connect или запросе URL, следует использовать CONTENTCACHEEXPIRES=
- Если кэша по умолчанию нет и в теге connect или запросе URL указано только CACHE= или CONTENTCACHE=, то для определения срока хранения используется свойство connect.connector.httpconnector.defaultcacheexpires службы WCM WCMConfigService .
Настройка абсолютного времени
Абсолютное значение задает дату и время истечения срока хранения документа.
Дата и время задаются в следующем формате:
- ABS {дата и время}
Например:
- ABS Mon, 29 May 2000 03:04:18 GMT
Поступление запроса на документ после этого времени приведет к очистке кэша и извлечению новой копии документа из внешнего источника.
Абсолютной дате должны предшествовать символы ABS; дата должна быть задана в одном из следующих форматов:
- Mon, 06 Nov 2000 09:00:00 GMT
- Monday, 06-Nov-00 09:00:00 GMT
- Mon Nov 6 09:00:00 2000.
- 6 Nov 2000 9:00 AM.
Первые три формата даты применяются в стандартном формате HTTP, а последний, краткий формат введен для удобства.
При использовании абсолютного значения даты и времени для определения срока хранения, кэшированные элементы остаются в кэше до истечения срока хранения. После истечения срока хранения исходный элемент извлекается при очередном запросе, а в кэш помещается копия, но поскольку абсолютная дата и время уже наступили, элемент сразу же станет устаревшим. Иными словами, при использовании абсолютных значений даты и времени элемент не может быть возвращен в кэш после истечения срока своего хранения. Все абсолютные значения времени заданы в формате GMT.
Настройка относительного периода
Вместо абсолютной даты и времени можно указать относительный период, в течение которого документ следует хранить в кэше. В этом случае дата и время окончания срока хранения вычисляются на основе времени помещения документа в кэш.
Относительный срок хранения документа в кэше можно задать, например, в часах или днях.
Относительный период задается в следующем формате:
- REL {целое}{единицы}
Прим.: Пробел после REL обязателен.
Целое значение должно задавать целое число единиц времени. Десятичные значения не поддерживаются. Единицы задаются одним символом без учета регистра:
- S: секунды
- H: часы
- D: дни
- M: месяцы
В первом примере срок хранения равен двум месяцам. Во втором он составляет 9000 секунд (2,5 часа).
Допускается указывать только секунды, часы, дни или месяцы. Минуты не поддерживаются, чтобы не усложнять интерфейс (буква M занята для обозначения месяцев). Очевидно, значение минут всегда можно задать в секундах (например, 5 минут - это 300 секунд).
Архив системы видеонаблюдения - это определенный объем информации (записей с камер видеонаблюдения), хранящийся на каком либо носителе. Чаще всего в качестве такового выступает жесткий диск (HDD) требуемой емкости (объема). Давайте рассмотрим основные вопросы, касающиеся архивирования видеозаписей с практической точки зрения.
Условно системы видеонаблюдения можно подразделить на следующие группы:
- любительские;
- полупрофессиональные;
- профессиональные.
Соответственно различными будут требования к способу создания архива и времени хранения записей.
Первая группа включает в себя видеонаблюдение установленное на даче , в частном доме или квартире . Как правило, такие системы имеют относительно небольшое количество камер, запись осуществляется на жесткий диск видеорегистратора.
Полупрофессиональными системами я бы назвал оборудование смонтированное в небольших магазинах, офисах и пр. С технической точки зрения они мало чем отличаются от первых. Время хранения архива в обоих случаях определяется собственником и может составлять от нескольких дней до нескольких недель.
Факторов, определяющих эти сроки, как правило, два:
- время, в течение которого может возникнуть необходимость получения информации для тех или иных целей;
- бюджет, выделенный на оборудование объекта системой видеонаблюдения.
Несмотря на очевидность первого пункта, здесь имеются некоторые нюансы. Дело в том, что современные системы видеозаписи позволяют создавать резервные копии нужных фрагментов. Резервирование чаще всего производиться на флешку (USB накопитель), хотя возможны и другие варианты - это зависит от модели и возможностей того же самого видеорегистратора.
Таким образом, задача определения требуемой глубины архива сводится к определению времени, в течение которого становится известно о событии, требующем дальнейшего разбирательства.
После этого создается копия нужных видеофайлов и хранится в течении любого необходимого времени, например, на время судебных разбирательств.
Профессиональные системы, установленные в банках, ювелирных магазинах, гипермаркетах имеют срок хранения информации не менее одного месяца. Для особо важных объектов архив записей с камер видеонаблюдения может иметь глубину два месяца и более. Кстати, требования к способам архивирования здесь жестче, но об этом ниже.
СКОЛЬКО ХРАНИТСЯ ЗАПИСЬ С КАМЕР ВИДЕОНАБЛЮДЕНИЯ
Организационные вопросы, касающиеся времени хранения записей с видеокамер, мы более-менее разобрали. Теперь можно перейти к технической стороне вопроса. Как уже говорилось, основным устройством хранения записей для простых систем видеонаблюдения является жесткий диск (HDD). Его емкость определяет время хранения архива.
Дело в том, что точного значения вам не рассчитает никто. Действительно, помимо таких, поддающихся учету факторов как:
- разрешение камеры видеонаблюдения;
- скорость сжатия;
- тип используемого кодека и пр.,
существуют трудно поддающиеся определению моменты, например, интенсивность движения людей в зоне обзора. Кроме того, она может быть разной для различных камер системы видеонаблюдения. В таком случае стоит определить требуемое время хранения для каждой видеокамеры, рассчитать нужный объем памяти для времени записи конкретной зоны, а полученные результаты сложить.
Однако, как показывает личный опыт, в большинстве случаев для систем видеонаблюдения, классифицированных мной в начале статьи как любительские, объема памяти в 1 Тб вполне достаточно. Но тем не менее приблизительно оценить емкость HDD все же стоит.
Стоит заметить, что расчет глубины архива принципиальных различий для аналоговых систем и IP видеонаблюдения не имеет. Безусловно, свои тонкости здесь присутствуют, но на "бытовом" уровне они не принципиальны.
ЖЕСТКИЙ ДИСК ДЛЯ ВИДЕОНАБЛЮДЕНИЯ
Как уже говорилось, подавляющее количество систем видеонаблюдения использует для записи видеоинформации жесткий диск. Помимо определенного объема памяти HDD должен иметь высокую надежность. При этом совсем не обязательно покупать специализированный жесткий диск для видеонаблюдения, тем более что это скорее маркетинговый ход, чем реальность.
В характеристиках жесткого диска всегда указываются такие параметры как:
- скорость вращения;
- объем встроенной памяти;
- тип интерфейса.
Первые два особого влияния на выбор HDD для систем видеонаблюдения не оказывают. Разве что, если говорить про скорость вращения шпинделя, то большое количество оборотов может опосредованно влиять на долговечность работы диска в видеорегистраторе.
Дело в том, что чем этот показатель выше, тем больше рабочая температура устройства. Для системы с большим количеством камер и высокой интенсивностью записи это может оказаться критичным. Скорости в 5400 или 7200 об/сек для наших целей вполне достаточно.
Что касается интерфейса, то большинство регистраторов используют SATA, к тому же они наиболее распространенные. Но тем не менее, при покупке диска на этот момент внимание обратите.
Для любителей статистики: наиболее востребованными для систем видеонаблюдения являются жесткие диски Western Digital и Seagate.
Хочу лишний раз напомнить, форматирование жесткого диска стирает весь архив, правда видеорегистратор об этом, как правило, предупреждает. А вот про то, что существуют два режима работы с HDD он не говорит, но знать это надо:
-
при заполнении жесткого диска запись останавливается;
или, если диск переполнен, то осуществляется перезапись - на место самых старых файлов записываются новые.
Еще о чем не стоит забывать:
- любой видеорегистратор имеет ограничения по объему поддерживаемого диска;
- существуют регистраторы с возможностью подключения двух HDD.
Все сказанное позволит вам подобрать нужный состав оборудования и обеспечить требуемый срок хранения записей. Но имейте в виду, при использовании рассмотренных вариантов выход из строя жесткого диска лишает вас всей ранее записанной информации.
Если требуется высокая надежность хранения видеоинформации, то следует использовать IP системы с хранением информации на сервере видеонаблюдения , а для создания и хранения архивов видеозаписи использовать RAID массивы. Дорого, конечно, но профессиональная система дешевой не бывает.
* * *
© 2014-2019 г.г. Все права защищены.
Материалы сайта имеют исключительно ознакомительный характер и не могут использоваться в качестве руководящих и нормативных документов.
