[Ruslan1 16]

jcxz, спасибо!

тоже думаю про похожее, так как хороших вариантов не так уж много.

 

Интересный вопрос- конфигуратор, в какой форме-формате задавать величины

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

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

Осталось выделить нужную часть для использования в конфигураторе, чтобы все не делать. Думаю для начала только кусок с "day d of week w of month m" реализовать, потом разовью если нужно будет.

 

То есть для примера ниже все уже задокументировано, и не велосипед. Может, и исходники tzset() пригодятся :)

Here are some example TZ values, including the appropriate Daylight Saving Time and its dates of applicability. In North American Eastern Standard Time (EST) and Eastern Daylight Time (EDT), the normal offset from UTC is 5 hours; since this is west of the prime meridian, the sign is positive. Summer time begins on March’s second Sunday at 2:00am, and ends on November’s first Sunday at 2:00am.

 

EST+5EDT,M3.2.0/2,M11.1.0/2

 

Here is an example for New Zealand, where the standard time (NZST) is hours ahead of UTC, and daylight saving time (NZDT), 13 hours ahead of UTC, runs from the first Sunday in October to the third in March, and the changeovers happen at the default time of 02:00:00:

 

TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0"

 

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

[SapegoAL 0]

Ну хорошо, врукопашную.

А кто как даты перевода задает?

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

Ну я так и задаю. У меня 407 проц. Я календарь веду. То есть я контролирую дни недели. И перехожу (если опция включена) на летнее/ зимнее время согласно принятому. времени перехода.

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

Сам проц не переходит.

У меня это контролируется в ТУ, поэтому проверяется на приёмочных и периодических испытаниях.

В старом приборе записывались даты и время перехода таблично... ))

Прикололся. )) Всё равно календарь веду, так я его вывожу одним из меню

[aiwa 0]

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

1.Фиксированное число/месяц.

2.Последняя суббота N-го месяца.

3.Первая суббота N-го месяца (хотя уже не помню - возможно можно было выбрать номер субботы определённого месяца).

Всё учитывали.

И перевод может быть на не целое число часов (полчаса например).

Добавлю, тоже по памяти, там еще был флажок полушария: северное или южное.

 

Интересный вопрос- конфигуратор, в какой форме-формате задавать величины

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

Я конфигуратор вставлял в стандартном формате, только миллисекунды перевел в секунды.

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

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

Изменено 24 января, 2017 пользователем aiwa

[Ruslan1 16]

Добавлю, тоже по памяти, там еще был флажок полушария: северное или южное.

мне кажется, что это лишняя сущность.

И что указать в экваториальных странах, которые и в том и в этом? (Свят-свят! не хотел бы я там что-нить ставить:))

Для вычисления достаточно просто честно проверять даты начала и конца указанной зоны при условии что событие не чаще раза в год, а не смотреть на начало-конец года.

 

в-общем, проникся я как tzset() работает, красиво. В будущем- нужно просто переменную TZ честно поддерживать, к чему и буду стремиться. Не нужно в этой области велосипедов, все уже придумано до для нас. Но сейчас сделаю еще более простую реализацию, чтоб не менять уже давно написанное в данном проекте.

[aiwa 0]

мне кажется, что это лишняя сущность.

 

Для вычисления достаточно просто честно проверять даты начала и конца указанной зоны при условии что событие не чаще раза в год, а не смотреть на начало-конец года.

 

Как раз этот флажок и нужен для проверки начала и конца указанной зоны, а точнее, его участие заключается в том что он для южного полушария всего лишь меняет местами начало и конец DLT-зоны. Может и не нужен, но используется в виде оператора if лишь один раз в год при построении границ зимнего времени.

 

[jcxz 184]

Добавлю, тоже по памяти, там еще был флажок полушария: северное или южное.

Не помню флажка.

А Вы разве в нашем проекте участвовали???

И Вас в нашем проекте тоже не помню

[aiwa 0]

Не помню флажка.

А Вы разве в нашем проекте участвовали???

И Вас в нашем проекте тоже не помню

Наверное в качестве флажка.

[KnightIgor 2]

Для вычисления достаточно просто честно проверять даты начала и конца указанной зоны при условии что событие не чаще раза в год, а не смотреть на начало-конец года.

Хотите, обломаю на взлете? В некоторых мусульманских странах (например, Марокко) на время Рамадана всегда действует зимнее время! Если Рамадан, который еще и "плывет" с годами в обратную сторону, как-то цепляет летнее время, начинаются очень интересные вещи! Алла, я в бар!

 

[Сергей Борщ 119]

Хотите, обломаю на взлете? В некоторых мусульманских странах

В некоторых странах летнее время вообще отменяют/восстанавливают по прихоти президента ;)

 

[Ruslan1 16]

В некоторых странах летнее время вообще отменяют/восстанавливают по прихоти президента ;)

Ну, для таких случаев есть три варианта, как и с Рамоданом:

1. просто не разрешать эту опцию и работать в "зимнем" времени или вообще в UTC.

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

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

 

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

 

P.S. еще раз Спасибо всем откликнувшимся!