Report GCA Site issues here [closed]

[caughtatwork]

Ahhh, I see.
You're too far South
But seriously, I see what the issue is and I can fix it, but this will need to wait until I get back to my code base tonight.

This should have been fixed.
A slight miscalculation of the lat/lon distances in Tasmania.

[Big Matt and Shell]

Thanks c@w. I'll break it up.

[canary]

Ahhh, I see.
You're too far South
But seriously, I see what the issue is and I can fix it, but this will need to wait until I get back to my code base tonight.

This should have been fixed.
A slight miscalculation of the lat/lon distances in Tasmania.

Thanks for the fix, but how did Tasmania affect the Blue Mountains!?!

[caughtatwork]

One degree is around 100km (er, lat I think).
The other one (lon maybe) changes down to about 86km per degree.
I was assuming (I know, I know), they were close enough in Oz to be inconsequential.
I was wrong, so in order to speed up queries I was restricting the lat/lon bounding box by the home co-ords +/- km/110.
That made the bounding box too small.
I now use 55km which should never be too small down our way.

[Richary]

How bizarre. I'm away on an invasion trip, and having logged a few GC caches including the event that the automatic updates might miss as there are too many logs in a row between updates thought I would generate a quick PQ to import to GCA. Which I did, got it and imported it here.

The ones I found today (the 9th) have come through to GCA as being found on the 10th, and the ones I found yesterday that hadn't already automatically updated on GCA have come through as today. The dates are showing correct on the GC site.

[caughtatwork]

This is a known problem with GC GPX files.
Let me grab an example.

Your log on this cache.
http://geocaching.com.au/cache/gc2p92w

Get a GPX file.
This is what you will see for your log.

Code: Select all

        <groundspeak:log id="153460952">
          <groundspeak:date>2011-04-09T19:00:00Z</groundspeak:date>
          <groundspeak:type>Attended</groundspeak:type>
          <groundspeak:finder id="32828">richary</groundspeak:finder>
          <groundspeak:text encoded="False">Another fun event, with it being out of Sydney a few new faces as well. Great to catch up with everyone on a beautiful sunny afternoon in a park with great views! A fun time and lots of chat had by all. Cheers.</groundspeak:text>
        </groundspeak:log>

2011-04-09T19:00:00Z
This is 09-Apr-2011 7:00AM Z (or GMT / UTC).
Convert that to Australian timezone and it becomes:
10-Apr-2011 5:00AM AEST

What's happening is that GC are setting their local timezone (for whatever their local timezone is) but inserting Z as the timezone.
Completely wrong and every man and his dog is converting Z to local and getting it wrong.

What needs to happen is that the Z time zone (if it's a GC GPX file) needs to be ignored or reset to Pacific (I think).
Let me have a look and see if I can bodge something in there to fix their dodgy timeazones.

[CraigRat]

How bizarre. I'm away on an invasion trip, and having logged a few GC caches including the event that the automatic updates might miss as there are too many logs in a row between updates thought I would generate a quick PQ to import to GCA. Which I did, got it and imported it here.

The ones I found today (the 9th) have come through to GCA as being found on the 10th, and the ones I found yesterday that hadn't already automatically updated on GCA have come through as today. The dates are showing correct on the GC site.

Did you log these caches with one of GC mobile apps (iphone/android)?????????

[Richary]

Nope - they were all logged on the web interface at GC.

2011-04-09T19:00:00Z
This is 09-Apr-2011 7:00AM Z (or GMT / UTC).
Convert that to Australian timezone and it becomes:
10-Apr-2011 5:00AM AEST

Not quite right, 1900 Zulu is 7PM England. But as you say would translate to 5am here the following morning.

Logs were made between 5 and 6pm tonight so why it chose 1900 Zulu I have no idea

[caughtatwork]

Yep, sorry my typo. PM not AM.

GPX files are always sent out in Z time so the local user of the file has the correct date / time.
Unfortunately GC introduced a bug some (many) months ago in that their TZ is not correct in the GPX files.
This is a known bug and reported in their forums, but they don't seem to respond to the cry from the masses to address it.
I have introduced a bodge into the import code to use the DATE, regardless of the TZ to set as the log date.
Please reimport the files and they should update the log date to the "right" one, regardless of whether the GPX file is right or wrong.

[Richary]

Yup, that's fixed them up to the right days. Thanks!

Not that it mattered for any stats apart from finds by day of the year

[caughtatwork]

I just wish they would fix the problem rather than have everyone in the world fix it for them.

[Richary]

It seems strange in the first place to timestamp a "found log". I might not get around to logging it for a few days if I have gone bush outside mobile data range. So the fact I log it on a certain date should be all that comes through. An hour is irrelevant and unknown - or is that something the GPX schema requires? In which case making it compulsory is flawed as the site I have logged the find on can't know when I found the thing.

The only log that is valid for an actual timestamp would be published. And in any case GCs one is wrong as I didn't type the logs at 5am tomorrow.

[caughtatwork]

That field is used as the date for which you create the log.
As it's a date/time field, it also holds a time.
The time is irrelevant at the moment as no-one asks you to log the time you find a cache.
But if they did, then they could add the time, in GMT, to the log so your logs would always be in order.

However, as they don't use the time part, it seems to be set to 19:00 if entered via the website, and then Z is tacked on "mindlessly". I say mindlessly as it's not a Z timezone time stamp. When people look at the file, they see a Z stamped timestamp and use it accordingly and then it's wrong.

What we don't know 100% is whether the date is "local", "offset" or "GMT" as the usual indicator in the timestamp is wrong, so it's a guessing game. I'm sure 19:00 GMT works for all US timezones, so I'm guessing that it's not perceived as a problem in the USA, but it is in the rest of the world.

[Yurt]

Because there are over 900 found logs the NSW Survey Marks locationless seems to take a long while to load now (no wonder!)
http://geocaching.com.au/cache/ga0094
I'm on a fairly fast connection but it takes at least 15-20 seconds to load up and sometimes freezes. I don't know if there's another locationless with as many logs but perhaps it can be divided into pages or maybe do the GC thing and only show the last X logs.

Not critical but something to watch out for.

[caughtatwork]

Your connection sucks then
Takes about 9 seconds for me, but I grant this is getting out of hand,.
I'll have a look at what we can do,.