time.h ARMCC Опции

[Pridnya]

Здравствуйте!
Как учитывается временная зона в стандартной библиотеке времени time.h?
Все что нашел в файле time.h - упоминание в функции strftime()

%Z is replaced by the timezone name or abbreviation, or by no characters if no time zone is determinable.

Попробовал все, что можно вывести, выводит все, кроме временной зоны:

time_t rawtime = 1480685759; // Fri, 02 Dec 2016 13:35:59 GMT
struct tm * timeinfo;
timeinfo = (struct tm*)localtime(&rawtime); // Convert time_t to tm as UTC time
char buffer [80];

strftime (buffer,80,"%I:%M%p",timeinfo);
puts (buffer); // 01:35PM

strftime (buffer,80,"%H:%M:%S%p",timeinfo);
puts (buffer); // 13:35:59PM

strftime (buffer,80,"%H:%M:%S",timeinfo);
puts (buffer); // 13:35:59

strftime (buffer,80,"%d.%m.%y",timeinfo);
puts (buffer); // 02.12.16

strftime (buffer,80,"%a_%A",timeinfo);
puts (buffer); // Fri_Friday

strftime (buffer,80,"%b_%B",timeinfo);
puts (buffer); // Dec_December

strftime (buffer,80,"%c",timeinfo);
puts (buffer); // 02 Dec 2016 13:35:59

strftime (buffer,80,"%j",timeinfo);
puts (buffer); // 337 (day of the year as a decimal number (001-366))

strftime (buffer,80,"%W",timeinfo);
puts (buffer); // 48 (the week number of the year (Monday as the first day))

strftime (buffer,80,"%x",timeinfo);
puts (buffer); // 02 Dec 2016

strftime (buffer,80,"%X",timeinfo);
puts (buffer); // 13:35:59

strftime (buffer,80,"%y",timeinfo);
puts (buffer); // 16 (year without century).

strftime (buffer,80,"%Y",timeinfo);
puts (buffer); // 2016 (year with century)

strftime (buffer,80,"%Z",timeinfo);
puts (buffer); // ???

Не знаю, как её задавать. Ведь с систем синхронизации будет время UTC+0, а у меня локальное UTC+3. Т.е. где-то должна быть временная зона.

Посмотрел у других - для PIC24 (компилятор XC16) в файле time.h есть переменная time_zone:

Код

extern int    time_zone;    /* minutes WESTWARD of Greenwich */
                /* this value defaults to 0 since with
                   operating systems like MS-DOS there is
                   no time zone information available */

Сообщение отредактировал Pridnya - Dec 5 2016, 06:52

[SasaVitebsk]

Я написал "типа этого". Специально проверял по разным. У меня всё работает. Уже 2 года выпускают изделие.
Вообще непонятно как там можно ошибиться.
Когда будете писать, контролируйте при GMT 0. А TimeZone это просто смещение. Ошибиться в операции сложения... ну я не знаю. ))

[Pridnya]

Я написал "типа этого". Специально проверял по разным. У меня всё работает. Уже 2 года выпускают изделие.
Вообще непонятно как там можно ошибиться.
Когда будете писать, контролируйте при GMT 0. А TimeZone это просто смещение. Ошибиться в операции сложения... ну я не знаю. ))

Я скриншоты привел для того, чтобы вы в своем онлайн-калькуляторе поискали, почему он пишет, что у меня на компьютере время такое-то, а оно на час отличается. У вас, наверное, ошибка, ведь часовые пояса у меня и у вас совпадают +3. Время на моем компьютере совпадает с "временем сервера", а не с "временем на вашем компьютере". Или я чего-то не понял?

Как прибавить три часа (3*3600) к UnixTime я знаю.

Сообщение отредактировал Pridnya - Dec 6 2016, 11:52

[Lagman]

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

У вас написано, что часовой пояс у вашего компьютера - Калининградское время (зима), а это как раз -1 час т.е. ваш winxp уже давно не знает правильного часового пояса, поищите в инете как это поправить через реестр.

[Pridnya]

У вас написано, что часовой пояс у вашего компьютера - Калининградское время (зима), а это как раз -1 час т.е. ваш winxp уже давно не знает правильного часового пояса, поищите в инете как это поправить через реестр.

Спасибо! Сделал все как здесь описано, теперь время с онлайн-калькулятором совпадает (только секунды не синхронизированы, но это уже другой вопрос).

Эскизы прикрепленных изображений

 

[Ruslan1]

Извините, то есть стандартизированного и документированного для Кейла пути работы с летним-зимним временем нет? И каждый свое делает как Бог на душу положит?
Грустно как-то. Нужно добавить в сорцы работу с летним/зимним- думал что лыжи не едут, а оказывается лыж просто нет совсем.

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

И, получается, что лучше просто иметь в конфиге startDateTime и endDateTime.

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

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

PS вот что бывает когда десятки лет работаешь в UTC, и вдруг надо в что-то местное переводить... Столько нового узнаешь об окружающем мире....

[jcxz]

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

Делал в своё время.
По памяти: у нас были следующие варианты задания в конфиге диапазона летнего времени:
1.Фиксированное число/месяц.
2.Последняя суббота N-го месяца.
3.Первая суббота N-го месяца (хотя уже не помню - возможно можно было выбрать номер субботы определённого месяца).
Всё учитывали.
И перевод может быть на не целое число часов (полчаса например).
Да и не переводил вобщем-то реально ничего (RTC). Часы реального времени шли всегда в линейном времени.
А уже если нужно было сезонное время, я определял - попадает-ли данная дата в диапазон летнего времени и включен-ли перевод? Если да - прибавлял к линейному времени смещение.
А вообще - перевод часов в системе реального времени, когда многое завязано на часы - это ОЧЕНЬ нетривиальная задача. Очень много проблем было с этим связано.
Особенно - когда на эти переводы ещё накладываются корректировки времени по интерфейсам связи и корректировки хода часов с ФАПЧ.
Служба реального времени - была одной из наиболее сложных частей ПО.

[Ruslan1]

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