Při vytváření zápisu o nalezení, nenalezení kešky a pod., se zapíše i čas. Jak jsem ale zjistil tak se mi zapisuje čas o 2hod menší, než je skutečný. Neporadíte, jak si to v GPS nastavit, aby tam byl skutečný čas? Díky za rady.
…čas je naprosto v pořádku - zapisuje se v časovém pásmu UTC 0 bez letního posunu. GPS nijak neovlivní v jakém časovém pásmu hledáš, takže zapisuje stále v UTC 0.
…ovšem každý pořádný soft si s tím musí poradit - třeba GeoGet s tím problém nemá a rozdíl ti automaticky upraví podle aktuálního časového pásma
Díky, to mi stačí, jen jsem to chtěl vysvětlit jestli nemám třeba jen něco špatně nastaveno.
Podle mne možná i záleží jak máš nastavenu časovou zónu. Pokud na automatiku, tak tam bude to UTC. Ale když tam ručně nastavíš to naše správné pásmo, tak by se to možná mohlo srovnat.
když tam ručně nastavíš to naše správné pásmo, tak by se to možná mohlo srovnat.
Srovnají se pouze hodiny, které vidíš na displeji, takže v realu na logování do logblogu máš čas dobrej. geocache_visits.txt je stále v UTC. Jak píše Sally&eL, tak GG se s tím popere.
Neda mi to a musim to upresnit a trochu si rypnout - Haluma odpusti :). Pokud je nastavena automaticka detekce casoveho pasma, je cas ukladan v UCT. To je pravda. Ovsem v obecne rovine s tim ma GeoGet (a rada jinych programu) problemy pramenici z toho, ze definice casovych pasem je sice jednoznacna, ale "slozita tvarem". Mnoho programu si to zjednodusuje (a GG k nim pokud vim patri take) tim, ze predpokladaji casove pamo nalezene kese shodne s casovym pasmem aktualne nastavenym na PC. V drtive vetsine pripadu to asi problem delat nebude, ale urcite se najdou i pripady, kdy ano. Jejich cetnost je ale zrejme tak mala, ze se nevyplati se s tim vice zabyvat. (Ani ja nejsem vyjimka - v jednom svem makru tuto problematiku v ramci zjednoduseni resim "obezlickou", sice jinou, ale take to nedava vzdy spravne vysledky.)
Chtěl bych se zeptat zda GG umí pracovat s geocache_visits.txt. Případně poradit jak na to? Díky
Naimportujes geocache_visits uplne normalne, jako jakykoliv jiny soubor.
Podle toho se ti kese v GG oznaci jako nalezene. A tusim do nejakeho tagu (fieldnote?) se ti ke kesi nahraje text, pokud v textaku nejaky byl.
Posouzeni pouzitelnosti necham na tobe 
Nemohu hodnotit aktuální verzi, ale GG tento problém úplně globálně neřeší. Myslím, že jsem postupoval dobře a po uploadu g_vis.txt časy neseděly. Souvisí to s tím, co zde již psal gord. Část logů totiž byla z Čech a část z Thajska. S tím si GG neporadil. Nechci ho tím nijak shazovat, nemyslím si, že jde o podstatnou funkci a program je podle mého názoru super, jen udávám příklad praktického využití. :c) Jinak pro naše časové pásmo mi časy (až na výjimky) sedí.
A kdyz si prijel do Thajska, tak si prenastavil casovou zonu v Garminu?
Petricius: takze se chova presne tak, jak bylo napsano vyse.
Neni to chyba, je to vlastnost.
GG proste prevadi cas z UTC, ktere je v geocache_visits.txt, do casoveho pasma pocitace. Pokud mas v pocitaci SELC, tak to proste bude logicky z Thajska spatne.
Neni to tedy o casove zone v garminu, ale v pocitaci s geogetem.
Tak v tom pripade jsem "precenil" GG, i kdyz na druhou stranu, jak by zrovna GG mohl vedet, ze s nim uzivatel pobihal po Thajsku, ze 
Neni problem podle souradnic poznat, kde ta keska je. Problem (relativni) je priradit spravne casove pasmo. Problem spociva v tom, ze casova pasma jsou po 15 polednikovyxh stupnich, ale je mnoho vyjimek, kdy hranice pasma probihaji vetsinou po hranicich statu. To znamena dalsi polygony, … Neni to neresitelne, ale nestoji to asi za tu namahu.