Closed GoogleCodeExporter closed 5 years ago
(Remark: "already written" refers to Issue 198.)
Some questions:
- Does this happen to all archived caches?
- Which options do you use? (May I suggest -Y? Does this reproduce the problem?
- Coordinates will be missing though.) You *do* use -z, I presume...
- Can you run in debug mode, limiting to one search page (or a few)?
Unfortunately the caches are listed in reverse chrono order... There should be
a plenty of lines with "date:" in them - do you see any irregularities with the
date formats?
- What are your date format, and language settings?
Original comment by Steve8x8
on 27 Sep 2013 at 8:39
- Does this happen to all archived caches?
Yes
- Which options do you use? (May I suggest -Y? Does this reproduce the problem?
- Coordinates will be missing though.) You *do* use -z, I presume...
I did it with the User Interface:
so no Y was set
- Can you run in debug mode, limiting to one search page (or a few)?
Unfortunately the caches are listed in reverse chrono order... There should be
a plenty of lines with "date:" in them - do you see any irregularities with the
date formats?
I have to do it at home ... but I will try to do it as a Comandline request for
a fake user to have only a few caches
No date format issues at all
- What are your date format, and language settings?
I guess you mean at GC:
Language:
English
Date Format:
2013-09-27
Original comment by HeinzBro...@gmail.com
on 27 Sep 2013 at 8:46
That's for a Basic Member, and I (also BM) cannot reproduce the issue (I've got
to use the "yourfind*" templates, of course), with -Y:
GC1T0B1 0.00000 0.00000 traditional 2011-05-21
GCV9Q0 0.00000 0.00000 traditional 2011-05-21
GC1YP5Y 0.00000 0.00000 traditional 2011-05-22
and without:
GC1T0B1 47.58470 11.11567 traditional 2011-05-21
GCV9Q0 47.56445 11.12645 traditional 2011-05-21
GC1YP5Y 48.15558 11.51165 traditional 2011-05-22
Looks fine to me.
Command line was:
geotoad -H -v -v -v -u XXX -p YYY -z -Z -x yourfindlist:yourfindgpx:list -o homers.findlist -q user Homer-S
I'm using 3.18.0 though...
Original comment by Steve8x8
on 27 Sep 2013 at 10:27
OK, I thought with this acc we have a quickeer chance to find the issue. Maybe
we have to try -q user KundH?
This was the initial user where I wanted to have the myfinds for GCStatistic ...
Original comment by HeinzBro...@gmail.com
on 28 Sep 2013 at 6:13
I did with the latest version 18.0 the identical request qith the user
interface and now everything is fine. Did you adapt something from 17.11 to
18.0? Anyway it worked for me :)
Original comment by HeinzBro...@gmail.com
on 28 Sep 2013 at 6:18
It's me again.
Do you have an idea why the official myfinds PQ and the geotoad one deliver in
the statistic app differrent weekdays and owners?
Original comment by HeinzBro...@gmail.com
on 28 Sep 2013 at 6:36
Attachments:
Some quite unsophisticated thoughts:
[#5 will take a while longer as I'm taking a week off (geocaching, y'know...)]
#6 might be r1440 in SVN
#7 if this affects only the last week there's an explanation ("today", "5 days
ago" etc. counted in GS's timezone, not ours; older ones with written-out dates
should be OK again - workaround: collect your data around noon UTC or at least
not too early in the morning as over there might still be yesterday)
Wild guesses, I know. Now off for some "sightseeing".
Original comment by Steve8x8
on 30 Sep 2013 at 11:27
#7b which I had left out before: GeoToad has no access to user IDs (as
discussed in another thread), can only read what's shown in the cache title -
and that may be completely off (owner may enter *anything* there). I don't see
a way to "fix" this.
#5: I have started a quick run with "-Y -Z -z" set to avoid too many requests
being sent to GC, and cannot find any 1980 date. I'm hesitant to run a full
query (without -Y, that would fetch every single cdpf file) right now, but that
might reproduce the bug you've been seeing. Which would only be of academic
interest since r1464 supposedly resolved a small issue related to date
mis-interpretation (which would show up in debugging output, btw).
If you can run with the latest SVN trunk the issue would have vanished, I hope.
May I ask you to check whether all your accounts use the same date
representation, again?
Original comment by Steve8x8
on 30 Sep 2013 at 1:07
I checked the date format in my "second account" and saw a different format!!!
I changed it immediately :)
happy caching!!
Original comment by HeinzBro...@gmail.com
on 30 Sep 2013 at 1:49
Hi, I have some more things.
How is the code for just adding the new found caches in an existing gpx file of
my finds? Is it possible?
I tried to change the finding time to the one I have in the official PC "My
finds" file but this changed nothing in the statistic for weekdays.
Original comment by HeinzBro...@gmail.com
on 5 Oct 2013 at 10:37
Re #11:
a. Using the -P option, you may limit the search to a defined number of
(20-entry) pages. gpsbabel can "merge" multiple gpx files into a single output
file. There are options to drop duplicates. So, possible, yes, but I didn't do
that yet. (What happens to sort order, for example?)
b. Mind to "grep groundspeak:date" both files, and compare? There must be
differences - and some characterization would help finding the problem's source.
I've already identified a hidden issue in date parsing (that must have been
there for many years) - which only shows up with certain date representations.
Did you already tell us which one(s) you're using? I must have missed that...
Original comment by Steve8x8
on 8 Oct 2013 at 11:05
look at #2 for format
I will try parameter -P 20 ... is it correct?
Original comment by HeinzBro...@gmail.com
on 8 Oct 2013 at 12:48
#2 is yyyy-mm-dd, but #10 was different.
-P 20 will give you 400 caches (20 pages, 20 entries each)
I'd recommend -Y (this won't give you coordinates and descriptions, but
anything else, and saves a lot of server accesses).
It'd be more helpful to compare the groundspeak:date lines, IMHO.
Original comment by Steve8x8
on 8 Oct 2013 at 1:24
#2 is the one I use now only
but in the readme.txt is written:
-P HTTP proxy server, http://username:pass@host:port/
???
But I do need the coordinates for the statistics, don't I?
This comparison I already did and found out the difference in time:
original PQ:
<groundspeak:date>2011-05-21T19:00:00Z</groundspeak:date>
geotoad myfinds:
<groundspeak:date>2011-05-21T08:00:00Z</groundspeak:date>
I changed in the geotad file the times to the 19:00 and tried again the
statistic but the deviation was still there???
Original comment by HeinzBro...@gmail.com
on 8 Oct 2013 at 5:57
One more question.
Would it be possible to give the myfinds caches a flag which makes them never
expire? So the request for myfinds would always take the local copy except the
new ones?!
Original comment by HeinzBro...@gmail.com
on 8 Oct 2013 at 6:05
As I failed to reproduce the issue reliably, and some changes have been
incorporated into 3.18.1 that address a couple of "weaknesses" in date handling:
Please upgrade to 3.18.1 or SVN >=r1480, and try to reproduce.
In particular, make sure that you don't mix language and time-format settings
if running with different identities - and, pretty please, tell which settings
you're using (part of debugging output, btw).
#7 has been moved to issue 283 - which is awaiting feedback as well.
Original comment by Steve8x8
on 21 Oct 2013 at 10:58
Re #16 (why didn't I answer this before?): I use to make the cdpf files
readonly for found caches - GeoToad won't overwrite write-protected files.
Don't know how to do this in Windows though.
Do you have any new ideas about the date discrepancy?
Original comment by Steve8x8
on 20 Aug 2014 at 7:06
Issue 283 has been merged into this issue.
Original comment by Steve8x8
on 27 Apr 2015 at 9:57
Issue 283, which seems to be unrelated at a first glance, also has date issues.
As this issue isn't making any progress, let's combine the two, and rewrite the
Summary line...
Original comment by Steve8x8
on 27 Apr 2015 at 10:00
This bug has last been reported more than two years ago, and my requests for help wasn't responded to. As I'm using GeoToad to produce input for GPStatistic myself, and never saw any discrepancy, I'm running out of ideas. If you feel you can provide more input, feel free to reopen this ticket.
Reopening after some changes of the timestamp handling code. Issue 283 is supposed to be a special case of this. (See the reopen message there for details.)
Original issue reported on code.google.com by
HeinzBro...@gmail.com
on 27 Sep 2013 at 8:24