Problems with Finds for Each Day of the Year

[+deepo]

Hi!

 

I'm trying to replicate the "Finds for Each Day of the Year" statistic by parsing my MyFinds pocket query. I'm using PHP, as I'd like to display my result on a webpage, and have possibility to upload a new MyFinds pocket query and have the calculations performed once again.

It appears that differences in number of caches found occur on log timestamps that are close to midnight, so I guess my problem is related to parsing timestamps.

I'm in Denmark, so my timezone is CET. So I convert the log timestamp to my timezone using:

function dateToTimezone($dateTimeUTC, $timeZone = 'Europe/Copenhagen', $dateFormat = 'Y-m-d H:i:s') {
  $date = new DateTime($dateTimeUTC, new DateTimeZone('UTC'));
  $date->setTimeZone(new DateTimeZone($timeZone));
  return $date->format($dateFormat);
}

dateToTimezone("2017-08-23T23:51:23Z") = "2017-08-24 01:51:23"

I then take only the month and day portion and create my Daily Finds statistic.

But there are huge differencies compared to the gc.com statistic.

geocaching.com:

Mine:

 

On e.g. June 5. I find 10 finds, while gc.com has 9. My 10 are (UTC - CET timestamps):

2006-06-05T07:00:00Z - 2006-06-05 09:00:00
2009-06-05T19:00:00Z - 2009-06-05 21:00:00
2009-06-05T19:00:00Z - 2009-06-05 21:00:00
2009-06-05T19:00:00Z - 2009-06-05 21:00:00
2009-06-05T19:00:00Z - 2009-06-05 21:00:00
2009-06-05T19:00:00Z - 2009-06-05 21:00:00
2009-06-05T19:00:00Z - 2009-06-05 21:00:00
2009-06-05T19:00:00Z - 2009-06-05 21:00:00
2013-06-05T15:23:26Z - 2013-06-05 17:23:26
2017-06-05T03:59:40Z - 2017-06-05 05:59:40

How can gc.com interpret these dates (UTC or CET) to fall on another date?

/Mogens

[+arisoft]

8 hours ago, deepo said:

How can gc.com interpret these dates (UTC or CET) to fall on another date?

About year ago my field notes started to jump future day if made after 16 o'clock. Now I stamp them manyally about noon to avoid this problem. I think that date will be composition of timestamp and timezone which is valid for the cache coordinates.

[+deepo]

2 hours ago, arisoft said:

About year ago my field notes started to jump future day if made after 16 o'clock. Now I stamp them manyally about noon to avoid this problem. I think that date will be composition of timestamp and timezone which is valid for the cache coordinates.

All finds on that date are in Denmark, so same timezone, but thanks.

I'll try a crude method of calculating correct time from longitude and see what I get.

 

/Mogens

[+deepo]

I couldn't find a way to convert latitude+longitude to a timezone in PHP, so I had to find timezones for the 23 country/state combinations I have found caches in.

But I get even more errors when I use localtime for the individual countries/states.

 

/Mogens

[+NYPaddleCacher]

30 minutes ago, deepo said:

I couldn't find a way to convert latitude+longitude to a timezone in PHP, so I had to find timezones for the 23 country/state combinations I have found caches in.

But I get even more errors when I use localtime for the individual countries/states.

 

/Mogens

There's a google timezone service that you could use.  (https://developers.google.com/maps/documentation/timezone/intro)

You'd have to make an http request to the service with a set of lat/long coordinates (in decimal degrees format) and it'll return the time zone in json format.  

[+fizzymagic]

The GC database does not include the time of any logs, even if the field notes you used to log the cache did.  The time is forever lost when the log is entered.  Yes, that is a problem in that the order in which you actually found your caches is not preserved, and erroneous dates when you didn't notice the timezone errors are preserved. These problems have been pointed out repeatedly to the folks at GC.com

Starting in 2003 or so.

Also, the GC time zone logic is pretty much nonexistent.  For my device's filed notes the system reads in the field note in  UTC time and then assumes that UTC == US/PST.  I keep hoping it will be fixed, but no luck.  I mean, there is no possible way that the GC system could possibly know the time zone of a cache find, right?  I mean, it's not like they have the location of the find or anything.

So you simply need to ignore the times of the logs, set the date to the log date in your time zone, and pick some random time (like noon) in your time zone as the local time for the log.

[+barefootguru]

10 hours ago, fizzymagic said:

The GC database does not include the time of any logs, even if the field notes you used to log the cache did.

I agree the timezone support is Byzantine, but last time I checked, the time was saved if submitting via the API.

20:00 and 19:00 Zulu are noon Pacific Standard/Daylight Time, which is old logs saved/edited through the website.

Since the ‘fix’ earlier this year, I think the API converts local time to Pacific, then saves with a ‘z’ designation.  Don’t know what the website does.

Prior to that, the API converted local time to UTC.

@deepo suggest you take note of the time, and log a find through the website, and another through the API, and look at what’s recorded.  Or give up and parse either GS’s or PGC’s date statistics 

[+deepo]

Success!!

Converting all timestamps from logs to "GMT-5", which just moves all timestamps 5 hours, results in 0 errors compared to gc.com.

I also contacted gc.com, who gave an answer today:

Quote

In May 2017, we updated our website and free Geocaching® app to sync to the time zone of the cache being logged. If you are using a API partner app that has not yet updated their app, the time zone may be incorrect when you log.

/Mogens

[+deepo]

Actually GMT-5, GMT-6 and GMT-7 all give the same Daily Finds statistic without errors.

Next I'll try to correct (on web) any geocache logs that cause a wrong date after conversion, and see if that helps.

 

/Mogens