+GlobalRat Posted May 6, 2017 Share Posted May 6, 2017 (edited) Pocket Query function to search for caches on Place During is limited with a start date that can not be earlier than 01/01/2000. This all makes sense considering that Geocaching only commenced in 2000. I see however that Placed Date in a Cache listing is not limited and one can place a cache with a place date as early as 01/01/100. I personally don't agree with this but seems there are numerous caches around the world that have placed dates pre 2000. These caches aren't picked up by PQ's relying on the date function which seems to be the only reliable way to manage a database of caches for a region. Surely the two date functions should be consistent? Perhaps publish date should become a selectable field? Thoughts. Edited May 6, 2017 by GlobalRat Quote Link to comment
+Isonzo Karst Posted May 6, 2017 Share Posted May 6, 2017 (edited) The current cache report form, CSP, limits back dating of new physical caches to one year (and one day forward, I assume for international date line issues). I'd like to see the edit form act the same way. (The current iteration of the edit form allows 01/01/1900 back dating, not 01/01/100.) My feature request would be to fix the back dating issue on the edit form to match the CSP. One year back dating only. Caches older than late July, 2005 have no publish logs. Because this is true, I think publish date as PQ field is unlikely. It would cause issues for unknowing cachers (just about everybody around now) - thread after thread after thread in these forums, whining about not getting all the caches.... You can use search to see pre-May 2000 (false) dated caches. A few years back there were 8 - now there are 18. Edited May 6, 2017 by Isonzo Karst Quote Link to comment
+GlobalRat Posted May 6, 2017 Author Share Posted May 6, 2017 The current cache report form, CSP, limits back dating of new physical caches to one year (and one day forward, I assume for international date line issues). I'd like to see the edit form act the same way. (The current iteration of the edit form allows 01/01/1900 back dating, not 01/01/100.) While I didn't save the change, I could change the placed date on one of my caches to 01/01/100 and it accepted it but wouldn't save, produced an error. I then changed one of my caches to 01/01/1900 and this was accepted and changed. I then tried the 1800's and this produced a server error. so you're right. Caches older than late July, 2005 have no publish logs. Because this is true, I think publish date as PQ field is unlikely. It would cause issues for unknowing cachers (just about everybody around now) - thread after thread after thread in these forums, whining about not getting all the caches.... Hmmm yes, I see the problem. You can use search to see pre-May 2000 (false) dated caches. A few years back there were 8 - now there are 18. How? Online search doesn't have a date filter and PQ will not allow search prior to 01/01/2000 Quote Link to comment
+Isonzo Karst Posted May 6, 2017 Share Posted May 6, 2017 Go to find a cache, put nothing in the search pane, and click "search", the little magnifying glass image. You'll get 3,000,000+ caches, sorted by distance from whatever your home coords are. Click date twice, to get them to sort on oldest first. Here's the URL for that search - on a weekend, it may be slow Quote Link to comment
+GlobalRat Posted May 7, 2017 Author Share Posted May 7, 2017 Thanks, I'll try again, previous attemots at that just produced errors. Quote Link to comment
+GlobalRat Posted May 7, 2017 Author Share Posted May 7, 2017 (edited) Worked in the quiet hours, thanks Currently 19. I suspect over time this number is going to increase. With the current focus on statistical caching and filling blocks in matrices, no doubt someone will come up with some challenge and there will be a rash of placements with fake place dates... Oh wait there already are.... Just not that pre-dated....... Yet! Edited May 7, 2017 by GlobalRat Quote Link to comment
+Isonzo Karst Posted May 7, 2017 Share Posted May 7, 2017 I've seen some date related project-gc checkers with a list of excluded GC Codes in the config file, so for challenge purposes, at least some script writers are keeping track of these. Quote Link to comment
+GlobalRat Posted May 7, 2017 Author Share Posted May 7, 2017 I've seen some date related project-gc checkers with a list of excluded GC Codes in the config file, so for challenge purposes, at least some script writers are keeping track of these. Yep, I guess all one can do is notify the challenge cache owners to update their scripts 1 Quote Link to comment
+Isonzo Karst Posted December 8, 2017 Share Posted December 8, 2017 The updated cache edit form has ended this. There were 19 in May, and now 54. https://www.geocaching.com/bookmarks/view.aspx?code=BM3Y09F Quote Link to comment
+Die C-SAU Bande Posted May 10, 2018 Share Posted May 10, 2018 I was just wondering, why some caches in our neigborhood are still not displayed in my Garmin Device (e.g. GC5KW65) Seems to be an error in the geocaching Pocket query or cache publishing design. Creating a pocket query should at least allow to enter a "from" date earlier than 01.01.2000 I am not sure what Groundspeak is heading for. They do not allow new API Access but they also do not fix this error. happy hunting Udo Quote Link to comment
+The A-Team Posted May 10, 2018 Share Posted May 10, 2018 14 hours ago, Die C-SAU Bande said: Seems to be an error in the geocaching Pocket query or cache publishing design. Creating a pocket query should at least allow to enter a "from" date earlier than 01.01.2000 The real error is with the COs that have used fake dates on their listings. If they used appropriate dates, there wouldn't be a problem. Quote I am not sure what Groundspeak is heading for. They do not allow new API Access but they also do not fix this error. IMO, HQ should indeed "fix this error"... by editing the dates on all of the problematic listings to remove the problem. Or at least give the COs a warning to change the dates on their own, and then force the change for those who don't respond. 4 Quote Link to comment
+badlands Posted May 11, 2018 Share Posted May 11, 2018 14 hours ago, The A-Team said: The real error is with the COs that have used fake dates on their listings. If they used appropriate dates, there wouldn't be a problem. Respectfully disagree. The real issues is that Groundspeak does not allow a "published date" search in the PQ. The API (e.g. GSAK) does. If you are recording and making a distinction between when the cache was placed and when it was published, then there is a valid reason to have both fields. One controlled by the cache owner and the other controlled by programming. In addition to recording when the cache was physically placed, some cache owners will use this as information required to solve a puzzle or as a hint in solving a puzzle. Quote Link to comment
+The A-Team Posted May 14, 2018 Share Posted May 14, 2018 On 5/11/2018 at 7:08 AM, badlands said: The real issues is that Groundspeak does not allow a "published date" search in the PQ. That has nothing to do with the issue being discussed here. Regardless of whether we're talking about a placed date or published date, no date earlier than May 3, 2000 makes sense on a geocache listing. Quote Link to comment
+badlands Posted May 14, 2018 Share Posted May 14, 2018 1 hour ago, The A-Team said: no date earlier than May 3, 2000 makes sense on a geocache listing. Is the "Date Placed" field significantly different that the "Description" field on the cache listing. It's just a field where a user can enter what ever they like. 1 hour ago, The A-Team said: On 5/11/2018 at 9:08 AM, badlands said: The real issues is that Groundspeak does not allow a "published date" search in the PQ. I stand by my statement. 1 hour ago, The A-Team said: That has nothing to do with the issue being discussed here. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.