Jump to content

Wegen falschem Datum der Logs (iPhone) Zeitzone ändern - Welche Probleme können entstehen?


Geohirse

Recommended Posts

Hallo GC´ler!

 

Ich nutze zum cachen die iPhone App und logge auch von unterwegs.

Leider sind die Logzeiten falsch.

Ein altbekanntes Problem.

Nun schrieb mich heute jemand an und gab mir einen Tipp.

Ich sollte die Zeitzone auf GC

http://www.geocaching.com/account/ManagePreferences.aspx

von GMT +1 auf +9 stellen, um dem Problem entgegenzuwirken.

Ich frage mich aber nun, welche Probleme dies mit sich bringen kann.

Eine falsche MYFOUNDS oder vielleicht andere Probleme ich an die ich noch nicht gedacht habe.

Viellecht hat ja jemand ein paar Tipps oder Anregungen für mich.

 

Und noch eine andere Frage. Wofür ist die Option "Adjust for Daylight Savings Time"? Auch auf der gleichen Seite wie oben.

 

Grüße

 

Geohirse

Link to post

Hi,

 

das mit dem falschen Log Datum ist wirklich ein nerviges Thema.

 

Problem ist, das wenn auf der Homepage geloggt wird, der Log lediglich als Datum angegeben wird. Dieses Datum wird als 12:00 Uhr PDT (Pacific Daylight Time) gespeichert. Alle Datumsangaben auf der Homepage werden ebenfalls als PDT ausgegeben. Wird also lediglich auf der Homepage geloggt, fällt es also nicht ins Gewicht.

 

Wird jedoch von einer App über die API geloggt, wird inclusive der Uhrzeit geloggt. Und alles vor 9 Uhr in Deutschland fällt in der PDT Zeitzone auf den Tag davor. Laut Angaben auf der Homepage stimmt die Anzeige eigendlich, denn ganz unten steht das es sich um PDT Zeiten handelt. Jedoch sieht halt jeder den Tag davor.

 

In meiner eigenen App (Looking4Cache) habe ich deshalb ermöglicht, die Log-Uhrzeit zu ändern. Dadurch hat jeder Benutzer die Möglichkeit, wenn er mal vor 9 Uhr loggt die Uhrzeit umzustellen, so das es nicht (optisch) auf dem Tag davor landet. Damit überlasse ich dem Benutzer die Wahl, ob er lieber die richtige Anzeige des Tags oder das echte Datum in der GS-Datenbank hat.

 

Grüße, Thorsten

Link to post

Hi,

 

das mit dem falschen Log Datum ist wirklich ein nerviges Thema.

 

Problem ist, das wenn auf der Homepage geloggt wird, der Log lediglich als Datum angegeben wird. Dieses Datum wird als 12:00 Uhr PDT (Pacific Daylight Time) gespeichert. Alle Datumsangaben auf der Homepage werden ebenfalls als PDT ausgegeben. Wird also lediglich auf der Homepage geloggt, fällt es also nicht ins Gewicht.

 

Wird jedoch von einer App über die API geloggt, wird inclusive der Uhrzeit geloggt. Und alles vor 9 Uhr in Deutschland fällt in der PDT Zeitzone auf den Tag davor. Laut Angaben auf der Homepage stimmt die Anzeige eigendlich, denn ganz unten steht das es sich um PDT Zeiten handelt. Jedoch sieht halt jeder den Tag davor.

 

In meiner eigenen App (Looking4Cache) habe ich deshalb ermöglicht, die Log-Uhrzeit zu ändern. Dadurch hat jeder Benutzer die Möglichkeit, wenn er mal vor 9 Uhr loggt die Uhrzeit umzustellen, so das es nicht (optisch) auf dem Tag davor landet. Damit überlasse ich dem Benutzer die Wahl, ob er lieber die richtige Anzeige des Tags oder das echte Datum in der GS-Datenbank hat.

 

Grüße, Thorsten

 

Aber wieso passiert da von Groundspeak nichts?

Das Datum ist doch eins der wichtigen Elemente beim geocachen.

Dann das falsche zu loggen, ist schon mehr als blöd.

Manche User wissen vielleicht gar nicht bescheid und cachen nur über die App.

Wundern sich aber irgendwann mal, dass die ganzen Daten falsch sind.

So macht das keinen Spaß.

Wissen die Entwickler der App denn schon bescheid?

Und wenn ja, haben sie dazu schon ein Statement abgegeben?

Regt mich schon tierisch auf das Ganze. :mad:

Link to post

Das Datum ist doch eins der wichtigen Elemente beim geocachen. ....So macht das keinen Spaß.

:) Ich bin immer wieder erstaunt.....Also für MICH steht erstmal der Cache und das Erlebnis vorne....dann kommt ganz lang nix. Und der Frage, ob jetzt ein um 1 Tag (!) verschobenes Datum im Log steht, kann ich genau EIN Problem zuordnen - nämlich wenn man lt. Datum einen Cache gefunden geloggt hat, der im realen Zeitsystem schon verschwunden ist. Das wird aber nicht unbedingt oft so vorkommen.

 

Ich will im übrigen garnicht wissen, wieviele falsche "Datums" aus Versehen eingetragen werden - incl. meinen. Ob in der Dose oder im E-Log.

 

Gruß Zappo

Link to post

@zappo:

Du verstehst das Cachen wirklich nicht, wie soll man den ohne exaktes Datum seine Matrix richtig voll kriegen, seine Statistik 100% korrekt halten und und und.... Das ist Cachen! Da soll GS sich mal bemühen und was tuen!

 

Falsche Daten werden nur (absichtlich) geloggt, wenn man seine Matrix, Statistik, .... frisieren will. Und auch das geht nur, wenn das Datum genau frisiert/gefälscht wird.

 

Deine Vorstelkllungen haben doch mit Cachen nix zu tun, "Erlebnis", "Cache" oder gar "Location", das ist doch alles nur Beiwerk. Wir brauchen genaue und richtige "Datums"!

 

Wann fängtst du an mit der Zeit zu gehen. Wohlmöglich loggst du noch zu Hause, gemütlich und schreibst, was du erlebst hast? So eine Zeitverschwendung, wenn man eine Dose gefunden hat kann man den weg zur nächsten Dose doch bestens nutzen um vom Eier-Phone aus schnell das Log zu schreiben.

 

(ACHTUNG: Dieser beitrag könnte Spuren von Sarkasmus enthalten)

Link to post

Also, ich hab jetzt mal im Duden unter Datum nachgeschaut.

 

Typische Verbindungen zu dem Wort Datum (computergeneriert) waren bei den Adjektiven z.B. wichtig, genau, konkret, magisch. Bei den Verben kam u.A. versehen und irren vor :lol: und bei den Substantiven so unerlässliche Sachen wie Name, Unterschrift, Zeit, Anlass und Kilometerstand (für Hardcorestatistikcacher).

 

Zusammenfassend würde ich sagen, das genaue Datum ist wichtig, vor allem in Kombination mit dem richtigen Kilometerstand, aber beim Loggen kann man sich ja auch mal im Datum irren. B)

 

Ob jetzt natürlich bei einem falschen Logdatum mit dem iPhone auch der Kilometerstand des Cachemobils was falsches anzeigt? :ph34r:

 

Oder um es kurz zu sagen: Zappo und Uwe sprechen mir aus der Seele.

Link to post

Ich greif das Thema jetzt nochmal auf :) !!

 

Um die Pro­b­le­ma­tik nochmal zu schildern...ich bin mit meiner Süßen gerade drauf und dran so eine Challenge zu meistern ;D. Eine echt harte Sache-366 Tage einen Cache pro Tag.

Nun haben wir schon einiges probiert und verschiedene Apps in gebrauch. Die von Groundspeak gefällt mir trotzdem bisher am besten ;D.

 

Nun zum Problem...wir cachen meistens nachts weil es uns beruflich nicht immer möglich ist tagsüber die nötige Zeit dafür zu finden.

Es kommt oft vor, dass wir in den nächsten Tag "hinein laufen" :) ! Wir speichern uns meist nen Bereich mit Caches, inet aus und dann gehts los.

 

Logischerweise speichern wir nur unsere Logs...wegen Off und so :) ! Das Handy speichert alle Logs einwandfrei und auch mit richtigem Datum ;D !

Zuhause angekommen ;)....gibt es fein Wlan :) ! Also alles versenden und gut ist :D....oder doch nicht ?

 

Tja...ich hab dann halt nur an einem Tag gecacht laut Geocaching.com ......obwohl es richtig hinterlegt ist auf der App!!! Datum steht bei gespeicherten Logs ja dabei !

 

Auf Cgeo funktioniert das und verblüffender Weise auch mit Fieldnotes....also warum bitte nicht so ? :S

Link to post

Wenn es für Dein Statistenzeuchs wichtig ist, mußt Du manuell loggen.

Cachen um Mitternacht hat einen großen Vorteil: einen Cache kurz vor und einer kurz nach Mitternacht suchen und Du mußt nur halb so oft zum lästigen Pflichtcachen raus.

Edited by radioscout
Link to post

@Harmonie Lover

ja, so ging es mir auch ne Zeit lang. Ist schon sehr nervig.

Ich verstehe immer noch nicht, wieso man das bei Groundspeak nicht unter Dach und Fach bekommt.

Stelle mir oft vor, ich schreibe um 00:05 Uhr einen Facebookfreund in Australien an und gratuliere ihm zum Geburtstag und er ließt diese Nachricht dann quasi in seiner Zeitzone am Vortag gegen Abend, was ja eigentlich Unglück bringen soll.

Hab mal gehört, es gibt da ne App, nennt sich Looking4Cache, kurz L4C. Die "sollte" so wie ich gehört habe, diesen Fehler beheben. Sagt mir, wenn ich falsch liege.

 

@radioscout

 

diese Statistik-Sache hat mich auch irgendwann genervt bzw. tut sie das heute noch. Aber es gibt halt so Freunde der Statistik und nunja,... lassen wir ihnen ihren Spaß. Ich habe Geocaching als kleines großes Abenteuer erlebt, wo man das loggen eines Caches mit langen Texten und Fotos schmückt und sich später gerne nochmal daran erinnert. Dass man sich hier fälschlicherweise an einen falschen "Tag" erinnert, sofern man nicht manuell nachgebessert hat, finde ich schlichtweg traurig. Es müssen ja nicht immer diese extremen Statistiker sein, für die die Plattform angepasst wird.

 

Wärst du oder jemand der sich mit der Matierie auskennt, so freundlich, und erklärst der Gemeinschaft nochmal, warum die Umsetzung bzw das Beheben des Problems nicht funktioniert?

Wenn ich auf der stinknormalen GC-Webseite auswähle, dass ich am DD.MM.YYYY um HH.MM.SS am Ort X war (den Cache logge), kann ich das doch auch in der App (theoretisch).

Warum kann das nicht umgesetzt werden?

Verzeih mir bitte mein endloses Kopfschütteln, aber es lässt sich von mir einfach nicht verstehen.

 

Hoffe du kannst es mir erklären, lieber radioscout :o)

Link to post

Wenn man bedenkt, dass dieses Problem auftritt, wenn man mit einem Gerät logt, das zum einen auf millionstel Sekunden genau über die aktuelle Zeit Bescheid weiss, und zweitens auch noch problemlos den Ort und somit die gerade zuständige Zeitzone (nebst gesetzlich verordneter Abweichungen davon, wie z.B. eine Sommerzeit) ermitteln kann, ist es schon ein ziemliches Armutszeugnis, das nicht auf die Logs in der Groundspeak Datenbank überführt zu bekommen.

 

Ich hätt ja noch Verständnis dafür, das beim herbstlichen Uhrenzurückdrehen, bei mehreren Logs in der Zeit von kurz vorm ersten 2 bis zum zweiten 3 Uhr an diesem Tag, die Reihenfolge der getätigten Logs durcheinander gerät – aber dass immer und nahezu überall auf der Welt, jeden Tag um die Geisterstunde herum alle vor Ort loggenden Geocacher damit ein Problem haben, und sich seit Jahren nichts daran tut, ist ein Armutszeugnis.

 

Und wenn es so ist, wie Groundspeak hier im Forum ja auch nicht müde wird zu beteuern,es ein größeres Problem ist, der Datenbank ein weltumspannend korrektes Datum beizubringen, sollte man sich überlegen, ob das nicht noch ganz andere Konsequenzen haben kann?

Link to post

ganz deiner Meinung, Thoric67. Ich verstehe aber nicht den Unterschied, beim von der GC-Seite loggen (Datum immer korrekt) und von der GC-App loggen (Datum teils falsch) ist. Wieso kann die App nicht das gleiche Paket abschicken, was man auch via Browser erstellt? Das muss doch irgendwie zu handeln sein, oder nicht? Ich würde es gerne verstehen!

Link to post

diese Statistik-Sache hat mich auch irgendwann genervt bzw. tut sie das heute noch. Aber es gibt halt so Freunde der Statistik und nunja,... lassen wir ihnen ihren Spaß.

Leider macht sich der Statistenwahn auch außerhalb der Statistencachens negativ bemerkbar. Sinnlose D/T-Werte und unsinnige Attribute sind nur die kleinsten sichtbaren Auswirkungen.

 

Wärst du oder jemand der sich mit der Matierie auskennt, so freundlich, und erklärst der Gemeinschaft nochmal, warum die Umsetzung bzw das Beheben des Problems nicht funktioniert?

Wenn ich auf der stinknormalen GC-Webseite auswähle, dass ich am DD.MM.YYYY um HH.MM.SS am Ort X war (den Cache logge), kann ich das doch auch in der App (theoretisch).

Warum kann das nicht umgesetzt werden?

Das kann ich leider nicht weil ich leider statt eines Vogelproduktfernsprechers nur das Konkurrenzprodukt habe. Aber ich will mich nicht beschweren, ich habe es von meiner Chefin bekommen und darf es auch privat nutzen.

Link to post
Ich verstehe aber nicht den Unterschied, beim von der GC-Seite loggen (Datum immer korrekt) und von der GC-App loggen (Datum teils falsch) ist. Wieso kann die App nicht das gleiche Paket abschicken, was man auch via Browser erstellt?
Aus der Erinnerung und heruntergebrochen:

 

Wenn du auf der GS-homepage einen Log abschickst, steuerst du ja im Prinzip die GS-Datenbank fern. Du machst, mit dem in deinen Usereinstellungen hinterlegten Zeitzone und dem dazugehörigen Datum einige Einträge in dieser Datenbank. Dort wird anhand deiner aktuellen Uhrzeit und dem dazugehörigen Datum ein Zeitstempel für den Log generiert und dieser entsprechend in die Liste der Logs einsortiert.

 

Wenn du aus einer Mobile App heraus logst, wird über die API die Datenbank angesprochen und die bekommt quasi nur die Logart, deinen Logtext und dich als Absender aber _keine_ Uhrzeit mit sondern protokolliert nur den Moment des Zugriffs (in Ortszeit Seattle) und packt diesen Zeitstempel an deinen Log dran.

 

Ich muss mal den thread hier im englischsprachigen Forum heraussuchen, in dem Moun10Bike das ganze erläutert – folgt bei Zeit und Muße.

 

Edit: Da ist er:

http://forums.Groundspeak.com/GC/index.php?showtopic=290221&st=0&p=4969537entry4969537

Edited by Thoric67
Link to post

es ein größeres Problem ist, der Datenbank ein weltumspannend korrektes Datum beizubringen,

Einfache Lösung: UTC verwenden. Das wird AFAIK auch in der Luftfahrt (intern) und der Meteorologie so gemacht.

Das wird ja gemacht. Sieht man ja am Fuße jeder aufgerufenen Cachebeschreibungsseite ganz unten:

 

Aktuelle Zeit: 11/25/2014 06:40:15 (UTC-08:00) Pacific Time (US & Canada) (14:40 GMT)

Letzte Aktualisierung: 7 days ago on 11/17/2014 15:21:40 (UTC-08:00) Pacific Time (US & Canada) (23:21 GMT)

Generiert aus:Unknown

Verwendetes geodätisches Datum: WGS84

 

Das Problem ist, dass es eben nicht stringent durchgehalten wird, bzw. beim loggen per API nicht die Ortszeit des Loggers mitgeschickt wird (die für die Datenbank fürs Einsortieren des Logs in die Liste der Logs ja irrelevant ist), sondern einfach ein 'Log eingegangen am xxxx um xxxx'-Stempel aufgedrückt wird.

 

Ich hatte es so verstanden, dass die Option des Kalenders mit dem man beim Logen über den Browser das Logdatum passend manipuliert, bei der API basierten Loggerei einfach komplett fehlt. Die haben gedacht: Da wird unmittelbar nach dem physischen Loggen online geloggt, also nehmen wir einfach den Moment, in dem der Log hier in Seattle eingeht, als Logzeitpunkt – feddich!

 

Das ist ja auch grundsätzlich nicht falsch, nur es sollte eben die Zeitzone des Loggenden mitgeschickt werden, um eben über den Logzeitpunkt die universelle Zeit ableiten zu können.

Link to post

Ich umgehe die Problematik indem ich per FieldNote logge. Dann sitze ich irgendwann gemütlich zu Hause am Rechner, arbeite die FieldNotes ab, lösche doppelte Einträge, sehe ob das Datum passt (auch hier wird vor 9Uhr der Vortag als Funddatum angezeigt) und kann viel angenehmer und ausführlicher loggen als auf dem kleinen Smartphone-Display.

Link to post

Ich umgehe die Problematik indem ich per FieldNote logge. Dann sitze ich irgendwann gemütlich zu Hause am Rechner, arbeite die FieldNotes ab, lösche doppelte Einträge, sehe ob das Datum passt (auch hier wird vor 9Uhr der Vortag als Funddatum angezeigt) und kann viel angenehmer und ausführlicher loggen als auf dem kleinen Smartphone-Display.

 

Ich glaube du hast unser hier geschildertes Problem hier nicht verstanden.

Schön und gut, dass du Zuhause dir die Zeit nimmst und alles noch mal akribisch nachbesserst.

Ich habe einen riesen Apperat und so klein sind die Dosplay gar nicht mehr. Habe sogar auf kleineren Displays gute und lange Texte schreiben können. Klar, das kann nicht jeder, aber ich kanns und darum gehts eigentlich auch nicht.

 

Wichtig ist mir, dass ich im nachhinein nicht nochmal nach jeder morgentlichen Cachetour meine Logs mit Datum bearbeiten will/möchte.

Wer das macht, der solls gerne tun. Ich jedenfalls möchte es nicht, da ich meine Erlebnisse und Gefühle direkt vor Ort und nach dem Heben ein mein Gerät eintippe und ich denke, da sind noch einige andere die so denken und fühlen und für die es momentan recht frustrierend ist.

Übertags ist es super. Nur in bestimmten Zeiten (abends bis morgens) cacht man schon wieder mit angespanntem Nerv, später, also nach der Runde wieder am PC editieren zu müssen.

Wenn man mal genau sein möchte, dann gbt es die Logmöglichkeit vom mobilen Gerät noch gar nicht, da diese nicht funktioniert wie sie sollte und ein Log vom mobilen Gerät sich eh nur zu bestimmten Zeiten ein Field Log darstellt.

 

Danke Thoric für den Link zum alten Problemthread, wo ich mich auch schon reingehangen habe.

Das Ganze läuft nun schon knapp 3 Jahre wo bis jetzt m.E. nix passiert ist. Der Thread ist schon sehr verstaubt. Letzter Beirag dort war 16 September 2013 <_<

Verstehe aber immer noch nicht wieso das so ist. Liegt vielleicht an meinen fehlenden Fach- und Englischkenntnissen.

Hat Mountainbike dort erklärt wieso, weshalb, warum? Hast du das verstanden?

Aber ich lese aus deinen Beiträgen heraus, dass du evtl. eine Möglichkeit siehst, wie man das Problem löst.

Täuschst du dich vielleicht oder hat der Laden einfach keine Lust den Kram umzusetzen?

Find ich richtig schade alles.

 

@radioscout ja ich hab auch nur ein iPhone zufällig mal bekommen.

 

Du schreibst:

Einfache Lösung: UTC verwenden. Das wird AFAIK auch in der Luftfahrt (intern) und der Meteorologie so gemacht.

 

Was heißt das? Wie hilft mir dieser Satz bzw dieses UTC. Wie verwende ich es und was sind ggf. die Nachteile?

Link to post

Also ich gehöre auch zu der Fraktion die sich nach dem Outdoorteil an den PC setzt und dann wird geloggt was gefunden wurde (was nicht auch). Manchmal kommt es vor das ich erst einen Tag später dazu komme und im Vormittagsbereich des Folgetages (ich habe noch nicht beobachtet wie lange genau) muss ich das Datum nicht auf den Vortag umstellen denn das steht da immer noch...

Ist nicht schlimm aber verstanden habe ich das auch nicht...

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...