Ahoj,
čirou náhodou jsem zjistil, že mi po importu keší dojde k posunu data nálezu některých keší o jeden den. Kdybych býval neplnil srpnové suvenýry, ani bych si toho nevšiml.
Zjistil jsem, že problém bude zřejmě nastávat během importu GPX souboru.
příklad keše (Oskeruse u Zalhostic):
log na geocaching.com: Found it 2013-08-30, v textu na začátku logu čas 18:35
log v Geogetu: 31.8.2013, 18:35
Když jsem se kouknul do importovaného GPX, našel jsem tohle:
<groundspeak:log id="345610897">
<groundspeak:date>2013-08-31T01:35:00Z</groundspeak:date>
<groundspeak:type>Found it</groundspeak:type>
<groundspeak:finder id="2625067">Mikeant</groundspeak:finder>
<groundspeak:text encoded="False">18:35 Odloveno spolu .... Diky za kes. </groundspeak:text>
</groundspeak:log>
Můžete mi někdo vysvětlit, jak došlo k tomu posunu, když log na gc.com je správně?
Není to jen jeden případ, ale jde o pár desítek keší...
Když použiju v Geogetu volbu Stáhnout nebo Aktualizovat nálezy, nic se nezmění.
Díky za náměty
Geoget - posunutý datum nálezu
Vytvořeno od
mikeant
, zář 12 2013 8:02
80 odpovědí na toto téma
#2
Publikováno 12 září 2013 - 8:09
On je spravne porad, jen v jine casove zone.
Problem je v tom, ze zatimco logujes na webu, cas se tam vubec neuklada, tak kdyz logujes pres Geocaching Live, cas se tam ulozi spravne. Ponekud Bordel.
Nicmene rychla oprava - ten datum a cas nalezu si muzes preci rucne opravit na co chces.
#3
Publikováno 12 září 2013 - 8:15
Nicmene i tak mam pocit, ze je to tam blbe. Je tam uvedeny cas 1:35 v casove zone UTC. My jsme v casove zone UTC+2, takze musis dve hodiny odecist. Tim se sice dostanes do spravneho dne, nicmene do 23:35. To 18:35 jeste neco chybi.
Takze asi ta apliakce, pres kterou jsi to logoval, poslala do Geocaching Live cas ve spatnem casovem pasmu.
Jinak by to, zrovna v tomto pripade, dopadlo dobre. 
#4
Publikováno 12 září 2013 - 8:25
Citace
Pravda, poslední dobou loguji pouze pres adrake, zkontroluji jestli tam je nějaké nastavení UTC.HaLuMa napsal/a:
Takze asi ta apliakce, pres kterou jsi to logoval, poslala do Geocaching Live cas ve spatnem casovem pasmu.
K té ruční opravě - ono je to sice hezké, ale to pak budu muset opravovat po každém importu. Už jsem to jednou opravoval, udělal jsem hromadný import a opět jsou data chybně :-(
Ještě přemýšlím, jestli nemám chbně formát datumu na gc.com - mám tam yyyy-mm-dd, ale někde jsem se dočetl, že má být mm/dd/yyyy. Tak jak to má být?
#5
Publikováno 12 září 2013 - 8:45
???
- Zadny import GPX nebo gc.live ti neprepise informaci o nalezu.
- Zadny import z GPX nebo gc.live neni zavisly na tom, jaky mas na webu nastaveny format datumu.
Problem s formatem byl jen kdyz sis aktualizoval nalezy v autostatu pomoci Geojarry. Nicmene v posledni verzi Geogetu je tento import uz ignorovan a tak nepokazi nic.
#6
Publikováno 12 září 2013 - 8:54
Citace
HaLuMa napsal/a:
???
- Zadny import GPX nebo gc.live ti neprepise informaci o nalezu.
Tak je asi něco špatně, teď jsem to opakovaně vyzkoušel. Opravil jsem přes "Nastavit nález" datum nálezu u GC3FYQW na 30.8.2013 (znovu načetl seznam, abych měl jistotu, že bylo opraveno), dal Databáze-Import souborů-Czech_Republic_Ustecky_T-T45-20L.gpx a zas tam mám 31.8.2013 :-(
#8
Publikováno 12 září 2013 - 9:04
Citace
mikeant napsal/a:
Citace
HaLuMa napsal/a:
???
- Zadny import GPX nebo gc.live ti neprepise informaci o nalezu.
Tak je asi něco špatně, teď jsem to opakovaně vyzkoušel. Opravil jsem přes "Nastavit nález" datum nálezu u GC3FYQW na 30.8.2013 (znovu načetl seznam, abych měl jistotu, že bylo opraveno), dal Databáze-Import souborů-Czech_Republic_Ustecky_T-T45-20L.gpx a zas tam mám 31.8.2013 :-(
1) Chceš radit ale nemáš vyplněný odkaz na svůj profil na gc.com. Jak se pak máme podívat co máš v logu ?
2) Píšeš o importu gpx souboru, není to v něm náhodou špatně ?
#9
Publikováno 12 září 2013 - 9:16
Citace
Arne1 napsal/a:
1) Chceš radit ale nemáš vyplněný odkaz na svůj profil na gc.com. Jak se pak máme podívat co máš v logu ?
2) Píšeš o importu gpx souboru, není to v něm náhodou špatně ?
Profil jsem opravil, měl jsem ho vyplněný, ale špatně, za což se veřejně omlouvám a sypu si popel na hlavu (mám číst návody, já vím...)
v GPX souboru chyba nebude, zkoušel jsem stáhnout přímo dotčenou keš z gc.com a přesto je to špatně.
#10
Publikováno 13 září 2013 - 6:50
Citace
HaLuMa napsal/a:
Ok, proverim to.
Koukal jsi na to prosím? Nikterak tě nechci honit, jen jsem celý napjatý, zda jde opravdu o bug nebo jen mám něco špatně. Děkuji
#11
toni-az
-
- Members
-
- 17 příspěvků(y)
Member
Publikováno 16 září 2013 - 17:40
Mně se to děje taky. Přes Geojarry to bývalo OK, teď jsem nahrál keše přes My Finds a spousta jich je o den později. Zjistil jsem už to, co tu padlo, a to že je to špatná interpretace TZ. Takže otázka asi bude hlavně tahle - dá se nějak donutit Geoget, aby si přepočítal TZ na naši? Případně naopak donutit gc.com, aby to do PQ ukládal v local time?
Při každém importu editovat PQ mi přijde hodně nepoužitelné.
Díky.
#12
Publikováno 16 září 2013 - 17:53
Geoget prepocet podle casoveho pasma dela! (jinak by nefungovaly spravne ani logy zapsane primo na webu).
Jenze tady slo o logy, ktere byly zalogovany s vadnym casem. S tim tezko neco udelam! Jako ze bych vesteckou kouli zjistoval, ktery cas je spravne a ktery ne?
Jediny problem v GG je ten, ze kdyz si to opravis rucne v databazi, ze se to nejak prepise zpet, coz by rozhodne nemelo. Ale jeste jsem nemel cas to proverit.
#14
toni-az
-
- Members
-
- 17 příspěvků(y)
Member
Publikováno 17 září 2013 - 8:33
Mám tam naše pásmo - Prague, Warsaw.
Jinak nemyslím, že by to bylo blbě zalogované, nějak si nedovedu představit, jak bych to udělal. To, co vím, že je blbě, jsem logoval přes web.
#15
Publikováno 17 září 2013 - 8:47
Ja si to predstavit dovedu. Web si totiz pamatuje datum posledniho logovani a pokud logujes vice kesi v jednom dni, nabizi ti porad totez datum. Kdyz ho nezmenis, mas hned spatny datum u logu. Chvilka nepozornosti, a je to.
Jeste jsem u GG nenarazil na spatne datum logu, ktere bych si nezpusobil sam (vyse popsanym postupem).
MHD/PID vybranych mest CR jako POI (diskuse)
GeoGet:
- Combine - automatizace opakovanych cinnosti (diskuse, dávky)
- Stator - statistiky y GeoGetu (diskuse)
- Spoiler - uložení spoilerů do GPS jako POI (diskuse)
- Náhrada GJ legálními postupy
#16
Publikováno 17 září 2013 - 9:18
Citace
Ale on psal že na webu má datum správně, chybně se stáhne do GG.gord napsal/a:
Ja si to predstavit dovedu. Web si totiz pamatuje datum posledniho logovani a pokud logujes vice kesi v jednom dni, nabizi ti porad totez datum. Kdyz ho nezmenis, mas hned spatny datum u logu. Chvilka nepozornosti, a je to.
Jeste jsem u GG nenarazil na spatne datum logu, ktere bych si nezpusobil sam (vyse popsanym postupem).
#17
toni-az
-
- Members
-
- 17 příspěvků(y)
Member
Publikováno 17 září 2013 - 11:01
Přesně tak, na webu je to OK, v GG o den později. Dokonce i v PQ je to o den později, ale jiného časového pásma.
#18
Publikováno 17 září 2013 - 12:28
Ne, neni to na webu OK! Viz ten priklad v uplne prvnim prispevku:
Uzivatel zalogoval "Found it 2013-08-30, v textu na začátku logu čas 18:35" Ale v PQ stazenem z webu je: 2013-08-31T01:35:00Z.
To Z na konci znamena Zulu, tedy casove pasmo UTC. My jsme v casovem pasmu UTC+2, takze kdyz to prepoctu do naseho casoveho pasma, musim pripocist dve hodiny (drive v diskuzi jsem to omylem odecital...) a dostanu 31.8.2013 3:35. A to neni spravne! Ten cas je o devet hodin jinde, a to je dost na to, aby spousta casu pretekala do jineho dne. (Geoget z toho vezme jen datum, a cas stejne bere z textu logu)
Takze mas-li pocit, ze je to na webu spravne, schvalne se podivej do tech dat v PQ, co tam leze a co z toho vyleze po prepoctu casove zony.
Uzivatel zalogoval "Found it 2013-08-30, v textu na začátku logu čas 18:35" Ale v PQ stazenem z webu je: 2013-08-31T01:35:00Z.
To Z na konci znamena Zulu, tedy casove pasmo UTC. My jsme v casovem pasmu UTC+2, takze kdyz to prepoctu do naseho casoveho pasma, musim pripocist dve hodiny (drive v diskuzi jsem to omylem odecital...) a dostanu 31.8.2013 3:35. A to neni spravne! Ten cas je o devet hodin jinde, a to je dost na to, aby spousta casu pretekala do jineho dne. (Geoget z toho vezme jen datum, a cas stejne bere z textu logu)
Takze mas-li pocit, ze je to na webu spravne, schvalne se podivej do tech dat v PQ, co tam leze a co z toho vyleze po prepoctu casove zony.
#19
Publikováno 17 září 2013 - 12:40
Nicmene koukam, ze i u kesi zalogovanych z webu tam maji v casech pekny hokej. Stare kesky maji cas 7:00Z nebo 8:00Z, novejsi kese maji 19:00Z ci 20:00Z. Ale jestli sedi datum, to jsem jeste nestihl prozkoumat.
To cele neni o nejakem korektnim prepocitavani, ale o odhadovani, jak u Groundspeku co pokurvili. 
#20
Publikováno 17 září 2013 - 13:13
A mimochodem, cas na jejich serveru je od naseho lokalniho casu prave o 9 hodin nizsi. To bude tech 9 hodin, co nam tam prebyva.
Aneb, vypada to, ze zmatek v casovych pasmech ma Groundspeak.
1 uživatel(ů) prochází toto téma
0 uživatelů, 1 návštěvníků 0 anonymních uživatelů
GeoGet
URWIGO
CWG
