Discrepancy between weekday distributions by GC statistics, and GCStatistic?

[GoogleCodeExporter]

There has been a single report (filed under a different issue number, 
unfortunately) that GC (on their statistics page) and GCStatistic (a popular 
tool to create a webpage that looks like GC's statistic page, with some 
additional features) would report different found-per-weekday counts.

As you may imagine, this is quite hard to check for someone who's got a 4-digit 
found count and/or no Premium Membership.

Is there anyone around who has a smaller number of found caches, *and* access 
to a "own finds" PQ/gpx, *and* is willing to compare the figures provided by 
GC, and GCStatistic? I'm somewhat lost...

Please *do NOT* upload your files here. Contact me (via twitter:@GeoToad_ or 
email) first. Thank you.

Original issue reported on code.google.com by Steve8x8 on 10 Oct 2013 at 7:41

• Merged into: #281

[GoogleCodeExporter]

9 months have passed, and I still can't reproduce the problem (as BM).
I'll close the bug as "WontFix" at the first anniversary...

Original comment by Steve8x8 on 20 Aug 2014 at 7:03

[GoogleCodeExporter]

This issue seems to be related to Issue 281, merging.

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

• Changed state: Duplicate

[steve8x8]

Unearthing this issue because today's commits may actually resolve it. Basically it's (at least that's my suspicion) caused by an interaction of user's set timezone, GC reporting back dates, and GeoToad projecting dates to UTC without taking into account that cache placement dates, and log dates, do not carry a time of the day. This may cause an off-by-one error when timestamps are built - which used to be "Z" ones (UTC/GMT). I'm afraid the original reporter disappeared from view a long time ago - any suggestion how to reproduce it, with GeoToad 3.26.2, and check whether today's git head behaves better?

[steve8x8]

Merging again into issue #281