the Seagnoid

I logged a cache in the Geocaching App, and also logged a retrieve of a trackable from that cache. On the website the cache correctly shows as found today, but the trackable was retrieved yesterday. I am guessing this is a timezone problem (I am in New Zealand, UTC+12). But it also means the trackable logging does not use the same date processing code as cache logging. Could you please make that the trackable date processing use the same code as the cache logging. (literally the same code, not just a copy of it!). But as I acquire souvenirs a day in the future, I guess Groundspeak are not fussed about date accuracy (the souvenir problem has been reported multiple times).

Leaving out the website was an oops. Rather a big one. Sorry, GC!! And re the separate jobs, the comment was that GC has only one job, not that the programming staff has only one job. But back to the topic on hand... GC - When is this bug fix scheduled?

I disagree. "Not fixing bugs" is something they are actually pretty good at. Some time ago I posted a list of about 8 bugs that were outstanding for years. Some got fixed by providing a whole new interface (arguably not a fix), other still exist. "Fixing bugs" is the thing they are bad at! What? Like keeping the servers running? Actually GC are already pretty good at this. There are very few server downtimes. The phrase "keeping the lights on" refers to the basics, and one (set of) broken links comes nothing close to being a basic part of identifying caches, locating, and then logging them.

Now that's unfair. Or even an outright lie. Their jobs are: Geocaching application Trackables (a mini-game within geocaching) Adventure labs Managing reviewers Promotion Policy Manage servers Pay the bills And probably lots more And each of these is a department in its own right. Geocaching is not run by a single person working out of a garage any more. Their developers are busy working on new features and modifying code for whatever new souvenir challenges are coming up. And doing back end stuff that we do not see (eg managing photo repositories, optimism SQL servers). They have project managers or product owners or the like whose job is to set priorities, and this problem has yet to be given a priority above other work (or maybe it has, and that other work is so low down it will never see the light of day!). YOUR job is to realise how a software house ACTUALLY works, and to do your part within that structure. If you want this fixed you have to raise the priority. You already know how to do that. Do it better. Sure, I disagree about the apparent prioritisation this bug's has been given. But frankly GC are pretty good at not fixing bugs for years and then rolling out a whole new interface instead. Maybe that is what will happen here (which I am sure will annoy the heck out of everyone, having to wait two more years before this is resolved)

Trackable logs show that the trackable is in or has visited a number of geocaches. The link to every geocache in the trackabvle log is https://www.geocaching.com/geocache/GC0 - which of course goes nowhere. To see this, open up a trackable page, eg: https://www.geocaching.com/track/details.aspx?tracker=TB9YP44 Hover over or click on the links to any of the caches that trackable has visited. In the meantime we can get around the problem by clicking on the log link, and clicking to the cache from in the log.

Still not fixed :-( Could we PLEASE ask the engineering team to stop work on new projects and fix the annoying bugs in the existing products?

There is a very annoying bug in that the resize parameters of an image in the cache description are forgotten when editing the cache page. Every time I change a bit of text I have to resize the image again. Especially annoying if I have to make an edit a year later and can't remember what the original image settings were! To replicate the fault: When editing a cache page (eg creating a new one) ... When using the user-friendly description editor Insert a picture Select save and view. Note the size of the image Go back to editing the description. Right click image, select image properties. Resize the image - eg enter 50%, or a number of pixels, into the width field. Select save and view - note the image is now resized. Go back to editing the description. change some text. Select Save and view. Note that the image is now the original size! The setting of the padlock has no effect on this.

When writing up a cache found yesterday (or any time in the past) the website remembered the date and auto selected it for the next log, which often is for another find on the same date. Lately it has stopped doing this - and I find I am often having to go back and edit my logs to correct the date. Really annoying. Can we please have the cookie setting returned and used so that the website remembers the last logged date (within this browser/cookie session). Anyone else also find this annoying?

At the time it came out I thought it was a good idea, but in practice it hasn't realized it's potential. If these flags were made available in the geocaching app they get more use.

I assume yelling will help, as the devs don't seem to be in normal range of this blog. Posted numerous times on this forum: lab cache finds reports dates incorrectly in the lab cache journal and in any souvenirs that result. For instance, the attached June Solstice souvenir says I was awarded it on the 24th June, but it is actually 7am, on the 23rd June New Zealand time, as I write up this post. And in USA it is still 22 June, in all time zones there. Perhaps see the date and time this post was created and compare that to the image I have attached.

Come on guys - the cache owner dashboard was an great tool for finding my caches that need maintenance. When are you going to fix it? Tomorrow would be good.

Some of these bugs have been outstanding for years, and have been commented on in the forums numerous times. Trackable ID error page does not help: Go Play > Trackables > enter an incorrect tracking id (the code on the trackable itself). This takes you to Geocaching > Trackable Items > Trackable Item Search, with the incorrect tracking id entered in the "By keyword" field. However entering a correct tracking ID in this field takes us to the same page. Either this page should not be used for incorrect tracking IDs, or the by keyword field should resolve tracking IDs. Incorrect dates in souvenirs, lab finds - the date math is wrong and often (usually?) uses a date one day in the future. Eg, I find a cache on 1 January and I get the New Year's souvenir dated 2 January. Lab caches are also a day out as seen in their journals. At the time, the 2nd January has not appeared anywhere on the planet. Geocache date finds are calculated correctly, please use that date math (in fact, please use that date code) for souvenirs and lab finds. This may be time of day related, as some people report the dates correctly. This is a big one guys!! Adlabs do not email the log (journal) to the CO. Why was this ever made into a thing??? Adlabs allow the CO to self log their own caches - a geocaching rule was implemented for non-labs caches preventing this around about 2016 (that's just a guess). This principle got missed on lab caches (and I would submit that self logged lab finds - and there are some - should summarily be deleted given that the code denying self logged caches was introduced long before lab caches were introduced. But then I am very black-and-white.) Total cache find count for each friend in the View Friends page is incorrect. One whole cache type (lab caches) is missing from from the count. There are probably more. Please feel free to add to this list.

Many thanks, barefootjeff!

Does any know why-oh-why GC strips transparency off png and gif image formats? Does anyone know a way I can get an image with transparent regions on a cache page (eg an html method to make white pixels of an image transparent)?

Jeepers Groundspeak - what is with your date processing? An Ad lab was released yesterday, was found today, and the lab page says the review log was posted... tomorrow!!! I am in new Zealand, there is currently nowhere on the planet that is tomorrow, so Groundspeak must have some really weird date math. Why not use the date math from the geocache find code? That code works perfectly.

Wow is this all it takes? I have about a hundred bugs (okay, not really - probably about 30 or 40) that have been ignored for ages - although all were reported here. Would be nice to see them all fixed. Maybe I should collate them to a single document...

There are many puzzles that actually rely on an animated gifs as a core part of the puzzle. A still image breaks this. As a result, many puzzle caches broke when Groundspeak suppressed animated gifs a few years back.

There are bugs that haven't been corrected for years.

Seriously? Groundspeak are testing new features in live? What happened to your test environment?

BTW - this is in Android.

Sometimes in the Geocaching App I get little blue dots in the menu strip at the bottom of the screen. The blue dot on the Profile icon is usually a new souvenir. But the blue dot on the Lists icon? It has been there for months now and I do not know what it is. I assume one of my lists has changed - but which one? Could we please have the blue dot replicate to lower levels in the menu all the way to the specific item. Thanks, Tom

Hi everyone - something that might help to identify the problem - on the website right click and in the context menu select "inspect". Have a look at the network, performance and memory tabs (The OP reports a memory leak, but it may be a network issue, as in slow file delivery)

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!