Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
-
- beginner
- Сообщения: 22
- Зарегистрирован: 23 июн 2011, 12:15
- Версия LabVIEW: NI LabVIEW 2012(x86)
- Контактная информация:
Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Добрый вечер! Приветствую всех участников портала. У Меня возник вопрос по конвертированию времени (Timestamp) в строку. Не мог ли бы Мне кто-нибудь помочь?
Есть простой ВП для преобразования времени из Timestamp в строковое представление по определенному шаблону и выполнения обратной операции - из полученный строки опять в Timestamp. Блок-схема - см. ниже...
Так вот выполнение этого ВП на Цели (sbRIO-9631) и на ПК (Windows 7) отличается. Для сравнения привожу Лицевые панели ВП после выполнения на ПК и Цели, см. ниже...
Как видно, в обоих случаях исходное значение Timestamp Source равно новому, полученному из строки New (from string), и значение исходного времени в секундах Source (sec) тоже одинаково для обоих случаев. Однако, вопрос возник вокруг обработки исходного времени на Цели. Как видно значения TimestampString и TimestampeRec отличаются от исходного Source на -4 часа. Судя по всему ВП "Format Into String.vi" и "Seconds To Date/Time.vi" при преобразовании вычитают 4 часа из исходного времени, а ВП "Scan From String.vi" прибавляет 4 часа к результату. Подскажите пожалуйста, чем вызвано такое поведение и как избавиться от его влияния (исключить вычитание 4х часов при выполнении ВП "Format Into String.vi" и "Seconds To Date/Time.vi") ?
Часовой пояс на Цели менял через MAX, результатов ноль. Настройки времени в MAX см. ниже...
Есть простой ВП для преобразования времени из Timestamp в строковое представление по определенному шаблону и выполнения обратной операции - из полученный строки опять в Timestamp. Блок-схема - см. ниже...
Так вот выполнение этого ВП на Цели (sbRIO-9631) и на ПК (Windows 7) отличается. Для сравнения привожу Лицевые панели ВП после выполнения на ПК и Цели, см. ниже...
Как видно, в обоих случаях исходное значение Timestamp Source равно новому, полученному из строки New (from string), и значение исходного времени в секундах Source (sec) тоже одинаково для обоих случаев. Однако, вопрос возник вокруг обработки исходного времени на Цели. Как видно значения TimestampString и TimestampeRec отличаются от исходного Source на -4 часа. Судя по всему ВП "Format Into String.vi" и "Seconds To Date/Time.vi" при преобразовании вычитают 4 часа из исходного времени, а ВП "Scan From String.vi" прибавляет 4 часа к результату. Подскажите пожалуйста, чем вызвано такое поведение и как избавиться от его влияния (исключить вычитание 4х часов при выполнении ВП "Format Into String.vi" и "Seconds To Date/Time.vi") ?
Часовой пояс на Цели менял через MAX, результатов ноль. Настройки времени в MAX см. ниже...
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Приветствую, pavel_urkaev,
Насколько я понимаю, это поведение обусловлено различными зонами времени. Самый простой способ - попробовать использовать Universal Time Container <%^< >T>.
Насколько я понимаю, это поведение обусловлено различными зонами времени. Самый простой способ - попробовать использовать Universal Time Container <%^< >T>.
-
- beginner
- Сообщения: 22
- Зарегистрирован: 23 июн 2011, 12:15
- Версия LabVIEW: NI LabVIEW 2012(x86)
- Контактная информация:
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Добрый вечер. Mark, это попробовал первым делом - результат тот же самый. Смещение именно на 4 часаRe: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Приветствую, pavel_urkaev,
Насколько я понимаю, это поведение обусловлено различными зонами времени. Самый простой способ - попробовать использовать Universal Time Container <%^< >T>.
-
- beginner
- Сообщения: 22
- Зарегистрирован: 23 июн 2011, 12:15
- Версия LabVIEW: NI LabVIEW 2012(x86)
- Контактная информация:
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Добрый день. К сожалению, последнюю неделю плата не на руках, как только получим к ней доступ, попробуем Ваше решение!Попробуй отключить коррекцию времени.
-
- beginner
- Сообщения: 22
- Зарегистрирован: 23 июн 2011, 12:15
- Версия LabVIEW: NI LabVIEW 2012(x86)
- Контактная информация:
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Добрый вечер. Предложение kiparym'мa не увенчалось успехом, аномалия с переводом времени в строку и обратно не исчезла. Однако, обнаружил, что при получении текущего времени цели ("Get Date/Time In Seconds.vi") к времени, указаному в MAX прибавляется 4 часа. С чем это может быть связано? Как видно, часовой пояс настроен на нулевое смещение (Гринвич)...
- Super Star
- adviser
- Сообщения: 228
- Зарегистрирован: 07 фев 2013, 08:37
- Версия LabVIEW: 2011
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
на своем контроллере замечал такую же вещь, что MAX показывает настройки времени одни и время одно, а в программе - совсем другое. Просто руками в коде +- делал 3 года.
я люблю свою работу.... Я приду сюда в субботу ...
-
- beginner
- Сообщения: 22
- Зарегистрирован: 23 июн 2011, 12:15
- Версия LabVIEW: NI LabVIEW 2012(x86)
- Контактная информация:
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Ситуация стала еще интереснее. ВП, представленный выше, был изменен для отображения текущего времени Цели в часовом поясе - CurrentTimeOnTimeZone и текущего времени цели по Гринвичу - CurrentTime (GMT+0). Блок-схема представлена ниже (новый участок кода выделен зеленым)...
Было проведено несколько экспериментов для разных часовых поясов и времени, установленных в MAX. Изменение текущего времени и часового пояса в Системе - ПК, как и следовало ожидать, на результаты не оказало никакого влияния.
Результат эксперимента для GMT+9...
1) Смещение при конвертации времени в строку: +5 часов,
2) Смещение текущей временной зоны от Гринвича: +9 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -5 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +9 часов.
Результат эксперимента для GMT+10...
1) Смещение при конвертации времени в строку: +6 часов,
2) Смещение текущей временной зоны от Гринвича: +10 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -6 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +10 часов.
Результат эксперимента для GMT+10 (как и во 2м случае, но через MAX изменено текущее время на Цели)...
1) Смещение при конвертации времени в строку: +6 часов,
2) Смещение текущей временной зоны от Гринвича: +10 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -6 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +10 часов.
Прослеживается зависимость: ВРЕМЯ В СТРОКЕ - ИСХОДНОЕ ВРЕМЯ = ТЕКУЩЕЕ ВРЕМЯ В MAX - ТЕКУЩЕЕ ВРЕМЯ ЦЕЛИ (Get Date/Time In Seconds) = СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа.
Кто-то может пояснить причину существования данного смещения времен (СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа)?
Было проведено несколько экспериментов для разных часовых поясов и времени, установленных в MAX. Изменение текущего времени и часового пояса в Системе - ПК, как и следовало ожидать, на результаты не оказало никакого влияния.
Результат эксперимента для GMT+9...
1) Смещение при конвертации времени в строку: +5 часов,
2) Смещение текущей временной зоны от Гринвича: +9 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -5 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +9 часов.
Результат эксперимента для GMT+10...
1) Смещение при конвертации времени в строку: +6 часов,
2) Смещение текущей временной зоны от Гринвича: +10 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -6 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +10 часов.
Результат эксперимента для GMT+10 (как и во 2м случае, но через MAX изменено текущее время на Цели)...
1) Смещение при конвертации времени в строку: +6 часов,
2) Смещение текущей временной зоны от Гринвича: +10 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -6 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +10 часов.
Прослеживается зависимость: ВРЕМЯ В СТРОКЕ - ИСХОДНОЕ ВРЕМЯ = ТЕКУЩЕЕ ВРЕМЯ В MAX - ТЕКУЩЕЕ ВРЕМЯ ЦЕЛИ (Get Date/Time In Seconds) = СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа.
Кто-то может пояснить причину существования данного смещения времен (СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа)?
-
- beginner
- Сообщения: 22
- Зарегистрирован: 23 июн 2011, 12:15
- Версия LabVIEW: NI LabVIEW 2012(x86)
- Контактная информация:
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Добрый вечер, приветствую участников портала. Выявлена причина описываемого смещения времени (СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа). Системное время, а именно часовой пояс системы (UTC+04:00) формирует компонент выражения в -4 часа. Раньше Я утверждал, что настройки системного времени не оказывают влияния. Однако, чтобы зафиксировать изменение часового пояса системы в результатах выполнения кода необходимо перезапустить среду LabVIEW (закрыть проект, закрыть стартовое окно LV, запустить LV - стартовое окно, открыть проект). Так же результат выполнения чувствителен к системной настройке - автоматическому переходу на летнее время и обратно. Привожу доказательства ниже...
Результат эксперимента для MAX GMT+0, PC GMT+0, без автоматического перехода на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +0 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: +0 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 0 = 0),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +0 часов (PC_TZ_Offset - MAX_TZ_Offset = 0 - 0 = 0).
Результат эксперимента для MAX GMT+0, PC GMT+4, без автоматического перехода на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +4 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: -4 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 4 = -4),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +4 часов (PC_TZ_Offset - MAX_TZ_Offset = 4 - 0 = 4).
Результат эксперимента для MAX GMT+3, PC GMT+4, без автоматического перехода на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +4 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +3 часов,
4) Смещение при конвертации времени в строку: -1 часов (MAX_TZ_Offset - PC_TZ_Offset = 3 - 4 = -1),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +1 часов (PC_TZ_Offset - MAX_TZ_Offset = 4 - 3 = 1).
Результат эксперимента для MAX GMT+0, PC GMT+0, с автоматическим переходом на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +0 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе (F): ДА,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: +0 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 0 = 0),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +1 часов (F -> +1).
Как видно, прослеживаются определенные закономерности (указаны в примечаниях к рисункам). Исходя из данной ситуации, можно сделать вывод, что системные настройки вносят ошибки:
1) При указании времени на Цели средствами MAX. То есть, значение указанное в MAX отличается от реального (получаем при помощи ВП "Get Date/Time In Seconds.vi") установленного на Цели на (PC_TZ_Offset - MAX_TZ_Offset).
2) В результаты преобразований времени при использовании: ВП "Format Into String.vi" - время, полученное в строке, будет отличаться от исходного на (MAX_TZ_Offset - PC_TZ_Offset); а ВП "Scan From String.vi" - наоборот, полученного время будет отличаться от исходного в строке на (PC_TZ_Offset - MAX_TZ_Offset). Причем, если "прогнать" время через последовательные вызовы ВП "Format Into String.vi" и ВП "Scan From String.vi", то исходное значение времени и конечное будут равны, но промежуточная строка будет отличаться.
Самое интересное, что если получить текущее время Цели вызовом ВП "Get Date/Time In Seconds.vi" (Target_Time_TS = MAX_Time + (PC_TZ_Offset - MAX_TZ_Offset)) и передать его для преобразования ВП "Format Into String.vi" (Target_Time_String = Target_Time_TS + (MAX_TZ_Offset - PC_TZ_Offset)), то полученная строка будет равна значению времени MAX (Target_Time_String = MAX_Time + (PC_TZ_Offset - MAX_TZ_Offset) + (MAX_TZ_Offset - PC_TZ_Offset) = MAX_Time).
И все бы ничего, но если работать со временем в виде строк и численном (например, UNIX Time) одновременно, то соответствия между значениями нет из-за смещения, вызванного настройками времени в Системе ПК.
Описанное поведение считается нормальным? Кто-нибудь сталкивался с подобными ситуациями или мог бы посмотреть, как дело обстоит на его RIO-системе?
Результат эксперимента для MAX GMT+0, PC GMT+0, без автоматического перехода на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +0 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: +0 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 0 = 0),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +0 часов (PC_TZ_Offset - MAX_TZ_Offset = 0 - 0 = 0).
Результат эксперимента для MAX GMT+0, PC GMT+4, без автоматического перехода на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +4 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: -4 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 4 = -4),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +4 часов (PC_TZ_Offset - MAX_TZ_Offset = 4 - 0 = 4).
Результат эксперимента для MAX GMT+3, PC GMT+4, без автоматического перехода на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +4 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +3 часов,
4) Смещение при конвертации времени в строку: -1 часов (MAX_TZ_Offset - PC_TZ_Offset = 3 - 4 = -1),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +1 часов (PC_TZ_Offset - MAX_TZ_Offset = 4 - 3 = 1).
Результат эксперимента для MAX GMT+0, PC GMT+0, с автоматическим переходом на летнее время и обратно
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +0 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе (F): ДА,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: +0 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 0 = 0),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +1 часов (F -> +1).
Как видно, прослеживаются определенные закономерности (указаны в примечаниях к рисункам). Исходя из данной ситуации, можно сделать вывод, что системные настройки вносят ошибки:
1) При указании времени на Цели средствами MAX. То есть, значение указанное в MAX отличается от реального (получаем при помощи ВП "Get Date/Time In Seconds.vi") установленного на Цели на (PC_TZ_Offset - MAX_TZ_Offset).
2) В результаты преобразований времени при использовании: ВП "Format Into String.vi" - время, полученное в строке, будет отличаться от исходного на (MAX_TZ_Offset - PC_TZ_Offset); а ВП "Scan From String.vi" - наоборот, полученного время будет отличаться от исходного в строке на (PC_TZ_Offset - MAX_TZ_Offset). Причем, если "прогнать" время через последовательные вызовы ВП "Format Into String.vi" и ВП "Scan From String.vi", то исходное значение времени и конечное будут равны, но промежуточная строка будет отличаться.
Самое интересное, что если получить текущее время Цели вызовом ВП "Get Date/Time In Seconds.vi" (Target_Time_TS = MAX_Time + (PC_TZ_Offset - MAX_TZ_Offset)) и передать его для преобразования ВП "Format Into String.vi" (Target_Time_String = Target_Time_TS + (MAX_TZ_Offset - PC_TZ_Offset)), то полученная строка будет равна значению времени MAX (Target_Time_String = MAX_Time + (PC_TZ_Offset - MAX_TZ_Offset) + (MAX_TZ_Offset - PC_TZ_Offset) = MAX_Time).
И все бы ничего, но если работать со временем в виде строк и численном (например, UNIX Time) одновременно, то соответствия между значениями нет из-за смещения, вызванного настройками времени в Системе ПК.
Описанное поведение считается нормальным? Кто-нибудь сталкивался с подобными ситуациями или мог бы посмотреть, как дело обстоит на его RIO-системе?
-
- beginner
- Сообщения: 22
- Зарегистрирован: 23 июн 2011, 12:15
- Версия LabVIEW: NI LabVIEW 2012(x86)
- Контактная информация:
Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Добрый вечер. mark был прав - проблема решена путем отключения автоматической поправки на часовой пояс (<%^< >T>) в элементах управления, индикации и константах TimeStamp, а также в строке формата для вызова ВП "Format Into String.vi".
Благодарю всех за содействие в поиске решения!
Благодарю всех за содействие в поиске решения!
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 4 Ответы
- 615 Просмотры
-
Последнее сообщение Artem.spb
-
- 2 Ответы
- 1019 Просмотры
-
Последнее сообщение milakhimov