Date issues: logging dates may be wrong (for archived caches, with GCStatistic)

[GoogleCodeExporter]

I did as already written a myfinds as PM

but I have issues with importing the file into my statistic app.

I found out, that the archived caches do not get the right logging date:
    <groundspeak:date>1980-01-01T08:00:00Z</groundspeak:date>

Original issue reported on code.google.com by HeinzBro...@gmail.com on 27 Sep 2013 at 8:24

[GoogleCodeExporter]

(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

• Changed state: InfoNeeded

[GoogleCodeExporter]

- 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

[GoogleCodeExporter]

Original comment by HeinzBro...@gmail.com on 27 Sep 2013 at 8:48

Attachments:

• ScreenShot003.jpg

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• ScreenShot001.jpg
• ScreenShot002.jpg

[GoogleCodeExporter]

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

[GoogleCodeExporter]

#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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

#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

[GoogleCodeExporter]

#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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Issue 283 has been merged into this issue.

Original comment by Steve8x8 on 27 Apr 2015 at 9:57

[GoogleCodeExporter]

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

• Changed title: Date issues: logging dates may be wrong (for archived caches, with GCStatistic)

[steve8x8]

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.

[steve8x8]

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.)