Я что то пропустил ? (некоторое время назад RX4HX вроде как говорил что автоотправки на eQSL не будет по принципиальным соображениям :que:) . Было бы очень неплохо (естественно - с возможностью отключения) )))
Но одинаковое "как округлять и как отправлять (по time on или по time off ) " всё равно не помешает , иначе есть большой риск попасть рано или поздно на апокалипсический сценарий : "среднестатистический хэм решивший выгрузить журналы за несколько лет с ужасом обнаруживает на сервисах сотни и тысячи дублей " (на текущем этапе когда LogHx пишет time_on из time_off JTDX такая вероятность действительно есть).
Судя по картинкам в моих двух постах выше и по тому что на eQSL везде в формате hh:mm - просто отбрасываются секунды (без округления в сторону ближайшей минуты). Пускай так (простота и единый стандарт иногда дороже правил арифметики ).
Вопрос лишь в том что на скрине в сообщении #3431 отчётливо видно разницу в 4(!) минуты по одному и тому же QSO - тут дело уже не в округлении а в разном подходе - JTDX шлёт на eQSL по time_on , а лог пишет (и шлёт на eQSL) по time_off (причём time_off из wsjtx_log.adi превращается в LogHX3 в time_on) .
Можно я уже не буду скринить adif из LogHX открытый в текстовом редакторе - там именно TIME_ON и никак иначе (совпадающий по времени с time_off в wsjtx_log.adi , на 4х минутах разницы очень хорошо видно).
Бог с ней с арифметикой и правилами округления , можно как то поправить в LogHX3 чтобы time_on соответствовало действительности (бралось из time_on в wsjtx_log.adi) ?
Хотя тут тоже есть подводные камни (например DX который ответил спустя полчаса отправит на eQSL time_off , естественно не совпадёт с нашим time_on ) .... в общем чем дальше тем страшнее ))))).
В идеале бы конечно и time_on и time_off и в JTDX и в LogHX3 (в JTDX уже реализовано в файле лога wsjtx_log.adi есть и то и то) соответствующие друг другу в разных софтах ....
+ возможность проставлением галочек в настройках выбирать по time_on или time_off отправлять на eQSL - тогда бы каждый хэм мог найти для себя приемлимый вариант и не опасаться дублей.