Секунда — это секунда, год — это год, а 2 января следует за 1 января.
Вы знаете, что заголовок наивен, если вы потратили время на изучение времени в контексте программирования. У каждого из нас был момент, когда программы делали что-то неожиданное или делали что-то в неожиданное время. Ниже я расскажу о типах Times, о которых вам следует знать. Зная об этих различиях и о том, для чего хорош каждый тип Времени, вы сможете избежать разочарований в будущем. Для целей этой статьи слово расписание будет соответствовать повторяющемуся расписанию с определенной датой и временем начала.
Семантическое время
Семантическое время является локальным для пользователя и независимым от региона. Примером семантического времени является будильник, который вы устанавливаете на своем телефоне. Когда вы устанавливаете будильник на 7 утра в Гринвиче, а затем прыгаете трансатлантическим рейсом в Нью-Йорк, вы ожидаете, что будильник сработает в 7 утра по нью-йоркскому времени. Это время будет меняться в зависимости от того, где находится или будет находиться пользователь. Приложения, работающие с семантическим временем, должны как минимум стремиться узнать текущее местное время пользователя. Во многих случаях это можно сделать, подключившись к локальному времени Устройств или Браузеров, поскольку они должны автоматически обновляться, чтобы отражать текущее местное время пользователя.
Семантическое время может храниться в любом формате, в котором сохраняется соответствующая информация DateTime: год, месяц, день, час, минута и секунда в зависимости от варианта использования. Семантическое время может храниться в формате ISO 8601 со смещением времени или без него; однако смещения времени следует игнорировать, а время интерпретировать по местному времени. использование времени со смещением может упростить код для хранения и извлечения DateTimes из вашего уровня сохраняемости.
Точно так же семантические расписания следует интерпретировать в локальном времени пользователя. Возвращаясь к нашему примеру с будильником, повторяющийся будильник на 7 утра каждый понедельник, вторник и среду всегда должен интерпретироваться как 7 утра по местному времени пользователя.
Абсолютное время
Абсолютное время зависит от региона. Они определяют точный момент времени в данном месте. Примером может служить личная конференция, которая состоится в 7 утра в Гонконге. Пользователям из других регионов необходимо будет знать время проведения конференции по гонконгскому времени, так как они едут туда для участия.
Пользователю может быть полезно знать семантическое время проведения виртуальной встречи. Однако следует соблюдать осторожность, чтобы различать для пользователя, отображается ли время в семантическом или абсолютном времени. БЫВШИЙ. Встреча состоится в четверг в 7:00 по вашему времени по сравнению с Встреча состоится в четверг в 17:00 США/Центральная
Абсолютное время должно КАК МИНИМАЛЬНО храниться в виде полных строк DateTime в формате ISO 8601 со смещением, если они предназначены для последующего отображения. Если время предназначено только для внутреннего систематического использования, то приемлемы числовые стандарты временных меток, такие как временные метки Unix или временные метки UTC. Помните в начале вашего проекта, возможно ли, что рассматриваемое время может КОГДА-ЛИБО быть запрошено для отображения, поскольку без захвата смещения во время ввода будет практически невозможно определить эту информацию в более поздний момент. Если вы окажетесь в такой ситуации, то изучите данные, связанные со временем, и посмотрите, сможете ли вы определить по ним местоположение. Например, используя местоположение конференции из нашего предыдущего примера, вы можете вывести смещение, создав DateTime в часовом поясе этого местоположения.
Расписания абсолютного времени бывают двух видов. Системные расписания и региональные расписания. Системные расписания используются реже и представляют собой последовательность времен с определенным смещением; например, запланированные функции сервера, которые происходят каждый понедельник в 7:00 UTC. Независимо от изменений локального времени сервера или пользователя, операция будет выполняться каждый понедельник в 7:00 UTC. Региональные расписания учитывают региональные изменения времени, происходящие в месте, указанном при создании расписания. Это требует сбора и хранения не только строки даты и времени ISO 8601 для запуска расписаний, но и соответствующего часового пояса IANA для времени начала, такого как US/Central. Это необходимо, так как смещение времени в этом регионе может измениться из-за соблюдения летнего времени или подобных ситуаций. Настоятельно рекомендуется использовать библиотеки DateTime, которые могут напрямую принимать часовой пояс IANA для вывода времени с соответствующим смещением. Попытка разобраться с часовыми поясами самостоятельно — путь к разочарованию. Хранение часового пояса IANA может выполняться рядом со строкой DateTime (например, в другом столбце таблицы базы данных) или как расширение самой строки DateTime ISO 8601. Первое приветствуется, поскольку стандарт ISO может измениться в будущем, а второе может затруднить миграцию в такой ситуации.
Заключение
Времена совсем не простые в глобально связанном мире. Когда вы привязываете время к своему Пользователю независимо от его местоположения, вам следует использовать Semantic Times. Когда вам нужно представить определенное время в определенном месте, вы должны использовать Абсолютное время и при необходимости преобразовать его в семантическое местное время пользователя, если это имеет смысл (например, виртуальная встреча с несколькими часовыми поясами). При создании расписаний помните о том, нужно ли вам учитывать изменения смещения региона, и в этом случае вы должны сохранить часовой пояс IANA региона в дополнение к строке даты и времени ISO 8601. Вооружившись этими знаниями и ментальной структурой, он должен сделать работу с DateTimes более простой и менее подверженной ошибкам в будущем.
