the Seagnoid

Groundspeak seem to have repeated their date library all over the place, and many of these libraries give different results. I am going to be generous and say this was intentional, but I can't for the life of me think why. So for reference, I am in New Zealand, which is UTC +12 or +13. Yes, this is all about timezone handling. "Ordinary" geocaching... works perfectly. Souvenirs - often awarded in the future - I qualify for a souvenir today but the date that is attached to the souvenir is tomorrow's date. Labs in the leader board come in on the wrong date (can't remember if it is yesterday or tomorrow) I know there are others, but I can't remember them at the moment. If I find them again I'll add a note to this thread. For instance, I was awarded the GCHQ souvenir on the 21 August 2022. The qualifying find was on the 20th. Once Upon a Time 2022 on 2 January despite finding a cache on the 1 January Good programming practice would be to have one date library, probably stored in your SQL server. Okay, I can understand that might need to replicated, but that should be avoided like the plague, but where it must replicated but could you please at least use the same logic? For reference the date a cache (including lab cache) is found should be based on the timezone that the cache is located in (locationless caches might need special handling). Awards, such as souvenirs, should use the date of the qualifying cache, or at least use the most recent date in the finders stats, and certainly not tomorrow's date! Incidentally this is a common problem - in that every time Groundspeak release a new feature, time zone handling is incorrect, at least it is for those of us that live this close to the dateline. I recommend that Groundspeak get a tester in New Zealand or Australia to test their timezone handling prior to new products being released. Or maybe set up a VM user client with UTC +13 for testing (and test for finds just before and just after midnight).

Drafts? two finger typing on a phone? No likely. I am sticking to my notebook, thanks.

I am logging my caches at home after a geotrip, and I am using the website geocaching map to identify the correct caches to write up. I add a search filter (eg a word in the cache name) and the query returns caches across the whole world and the map zooms out to match. I just have to zoom back in again. I find this really annoying. Could we please limit the search for caches matching the filter criteria to just those within the search window or to a radius that approximates that (up to the limit that the search returns). In other words add the map centre and zoom level as a fixed component of the search filter. If I wanted all caches in the world, I would zoom out to all of the world first. But the majority of the time I am focused on one small area. Anyone else find this auto-zoom out feature annoying? Auto-zoom in is nice, but frankly, that can be dropped as well if required to fix the auto-zoom out problem. Please assume that the current centre and zoom level is what the user wanted and don't change it!

I have noticed that EVERY time that Groundspeak releases a new product, there are timezone errors. This is not surprising as a) handling timezones correctly is a non-trivial thing and b) hard to test - the developers in Seattle see their times coming through correctly. In fact, there is still a timezone problem outstanding - see There are two parts to a solutions for this. First Groundspeak needs a standard library of code for producing display dates, that show the found date for the country that the cache is in (not for the country of the cache finder!). Obviously there would be a number of these code snippets - one for SQL, one in the web language (eg java or whatever it is you use) - or maybe just the SQL one is all you need. This library obviously already exists, although maybe it has not been pulled out to a standalone function, as most of the site processes timezones correctly. But let's face it - having chosen the wrong date handling code in error is hard to pick up when the testing is in the same timezone as the development. Which leads to the second part of the solution. Partner with a tester in a problem timezone. Best would be a someone in New Zealand or Australia. I am happy to offer my services as a tester (for free) - I live in New Zealand, where the time is UTC +12 or UTC+13. Alternatively I can point you to some excellent web developers who are also geocaching mad. While I am not employed as a developer I have written a number of small applications and utililties, lately especially for challenge checkers for Project-GC. Not that you need anyone who knows how to code as a tester, but it help to have someone familiar with concepts, etc. I hope you take up my offer. regards, Tom

I have notice that there are still time zone errors with lab cache dates in the leader board - some of my lab caches finds (depending on the time that I found them) are showing up on the wrong date. Note that I am in New Zealand - UTC+12 or UTC+13.

The version of OS is thus not relevant as the code is obviously not attempting to use current time as might be reported by my system (given that it is using a date in the future). I used the latest version of Brave browser, but that is obviously not relevant either, for the same reason.

I logged this through the web site from a PC. Cheers

I have no finds!! See this I posted in a wrong thread

Ah, thanks - missed that . Oops!

Or maybe a better option is to have a filter setting save option for default load at application startup. Note that this should not automatically save the current filter!

There is a bug in the handling of the Completed filter. See

With the latest release of the Adventure Lab app (App version 1.3.21 build 2679 on Android) there is a disconnect between the filters and the profile setting Hide completed. If Hide completed is on then when starting the app the filter option Completed status Completed is off and completed adventures correctly do not show. Ticking filter status Completed correctly shows the completed adventures, and turns off the setting Hide completed. If you then unticking filter status Completed (so that now all filter settings are unticked) the map shows both completed and uncompleted adventures. So ticking or unticking the Completed filter both show completed adventures. The solution is to keep the profile setting Hide completed, and have this stored as a separate parameter from the filter option. The default filter option should be tick all and this should be loaded at application startup. The profile setting is then copied to the filter setting. As some filter options are now unticked, the filter icon on the map screen would show that filters have been selected. Alternatively, if you want the filters to show a filter out rather than a filter in, then the default filter is all unticked, and the Profile option is inverted and copied to the filters, thus ticking it.

If I click my avatar > View Profile > Geocaches > Caches found > click any cache type then instead of a list of the caches I have found I get the attached image showing zero results. If I then deselect Found by me, leaving Found by the Seagnoid in place then the list of caches appears. Oddly the fault does not appear for TwigNZ. May be related to Winnie51's problem:

In New Zealand, today is 22 Feb 2022. In Seattle, at the time I was awarded the Deuces Wild souvenir, it was 21 Feb 2022. Except the date on my souvenir is 23 Feb!! Did someone get the time zone math wrong and add a day instead of subtract a day? Incidentally, the NZ Mega 2020, GC87777, was held on and attended logged on 22 January, not the 23rd as it shows in the souvenir. See attached image.

When editing a cache and clicking Save And Exit we now get the warning that changes may not have saved. Changes are actually saved, so its not a big problem, just annoyingly misleading. (Microsoft edge, Brave, probably others)

I have a puzzle cache with a number of waypoints, GC3XWHY. A change at one of the waypoint locations requires me to make a change to the waypoint, but when I click Edit Cache or Add/Edit Waypoints no waypoints are listed. Clicking on Add Waypoint on the cache edit screen has no effect at all. (Microsoft Edge)

"Rule" is exactly the word I meant to use. Logging ones own geocaches was frowned on so much that Groundspeak modified the API and website to prevent it. By specifically disallowing own logs they effectively made it a rule. I'm just surprised that they did not follow their own policy.

Another area for improvement - please have the AL log emailed to the AL owner, same as happens with other geocaches.

A standard geocaching rule implemented many years ago is that cache owners are not able to log finds on their own caches. The website and API were modified to enforce this . The Adventure Lab application allows lab cache owners to log finds on their own lab caches. Could we please get this fixed (and perhaps delete all those self logged logs as the adventure lab app came out well after the rule was introduced)

A lab cache is a single find, an adventure lab is a set of five (sometimes more) lab caches. Lab caches have always been counted in statistics.

Also the unpublished hides page - https://www.geocaching.com/play/owner/unpublished

Also Unpublished hides - I have a cache ready to submit and now I can't! https://www.geocaching.com/play/owner/unpublished

Problem is fixed! Many thanks all.

As Viajero Perdido says, it is obvious that pocket queries are working fine for the vast majority of people. Try a pocket query from a computer you have never used before. If that works then the problem is likely to be bad cookies. Delete them all and try again.

At first I thought this was a bug in the Adventure Lab mobile application, but it looks like it is a website processing fault. For countries that are a long timezone away from Seattle, the date a lab cache is posted in Geocaching.com varies. Note that I live in New Zealand, 20 hours ahead of Seattle. I logged a lab cache approximately 8:30pm, New Zealand time, just after midnight of the same day, Seattle time. The date is correctly recorded in My profile > Geocaches > geocache finds > Lab caches, however the date here is not the date used to post the find into the general geocaching statistics. I am running a streak at the moment and and the streak was not updated after logging the adventure lab. Luckily I had found another cache so that my streak continues. Please correct the dates that adventure labs are logged into geocaching statistics to ensure that it uses the date on the mobile device.