Jump to content

An observation about the "hidden date"


Recommended Posts

What is the real importance of the date on which a cache was hidden? There is an option for limiting a pocket query to caches hidden during a given time frame. There are challenges that entail finding caches hidden during each month since the beginning of geocaching. People seek out the oldest cache in a given state or county.

 

When I had to replace one of my caches recently, I realized that the hide date is really irrelevant.

 

I initially hid the particular cache in 2008. It stayed there until 2015, when it was muggled. The replacement is similar and in the same location, with the same GC number. But it is not the cache I hid in 2008.

 

I'm not going to archive the old cache and publish the replacement as a new one. There is no reason for anyone who found the original to revisit the location and they will get no new experience in finding the replacement.

 

But someone who finds the replacement is not finding the cache I hid in 2008, even though the cache page says it is a 2008 cache.

Link to comment

Like many other parts of this wonderful hobby (like FTF) it has become important because some people decided it is when it really isn't. You can change it if you want with the edit tool but if you do and that is someone's cache for that placed by month their challenge fulfillment will go away. If you are really concerned about your cache you could have archived the old one and placed a new one although there is some issue about that and the reviewer may ask a couple of questions about why when it comes up.

Link to comment

But someone who finds the replacement is not finding the cache I hid in 2008, even though the cache page says it is a 2008 cache.

 

Yes they are. They're not finding the same container, that's all.

A cache is not simply the container... it is the whole experience.

The listing, the history of the location and scenery... even the logs on the cache since the beginning are part of it.

 

Even the owner changes in 8 years... I did. :)

Edited by RuideAlmeida
Link to comment

But someone who finds the replacement is not finding the cache I hid in 2008, even though the cache page says it is a 2008 cache.

 

Yes they are. They're not finding the same container, that's all.

A cache is not simply the container... it is the whole experience.

The listing, the history of the location and scenery... even the logs on the cache since the beginning are part of it.

 

Even the owner changes in 8 years... I did. :)

 

Up to a point, i agree with HH242. I've seen some old cache listings that hardly resemble the original hide. Moving a container 50 feet or more, changing its size and/or replacing with something not remotely resembling the original, removing a stage or two from an original multi listing, unfortunate changes in the area, etc,,, are all things that pretty much make it a different cache. As a cache owner, i understand why people try to keep their older cache listings going. I have a couple myself that i try to maintain as close to original as i can but if it comes down to it, they'll have to go if the change ends up being too great.

Link to comment

I've seen some old cache listings that hardly resemble the original hide.

The OP said, "There is no reason for anyone who found the original to revisit the location and they will get no new experience in finding the replacement." So that statement confirms it's the same cache with simply a replacement container, so the original 2008 hidden date is correct.

 

I agree that if there are significant differences, it would make sense to hide a new cache with its corresponding new hide date. But this seems to be a clear case where no new cache is being hidden, only a missing container being replaced.

Link to comment

Sometimes, the "hidden date" of a puzzle cache is a clue to solving the puzzle.

 

And as far as the difference between the "hidden date" and the "published date", I'd rather Groundspeak make the "published date" more usable (e.g., searching for recently published caches), rather than force the "hidden date" to match the "published date". If a cache was hidden in October, but wasn't published on geocaching.com until March, then I think the "hidden date" should reflect the fact that it was hidden in October. If that causes problems for people looking for caches published in March, then the solution would be to make it easier to search for caches based on their "published date", not to force the "hidden date" to be something other than the date the cache was hidden.

Link to comment

And as far as the difference between the "hidden date" and the "published date", I'd rather Groundspeak make the "published date" more usable (e.g., searching for recently published caches), rather than force the "hidden date" to match the "published date". If a cache was hidden in October, but wasn't published on geocaching.com until March, then I think the "hidden date" should reflect the fact that it was hidden in October. If that causes problems for people looking for caches published in March, then the solution would be to make it easier to search for caches based on their "published date", not to force the "hidden date" to be something other than the date the cache was hidden.

 

The "hidden date" is the day the cachelisting was made. Caches with the longest difference between hidden and published are mostly caches published for events where a lot (100+ ) listings are created over a period of time and caches are published in the evening on the date of the event. The hidden date isn't even the date the cache is hidden because that may well be the day before the event. Hidden date = listing created date.

Link to comment

The "hidden date" is the day the cachelisting was made. Caches with the longest difference between hidden and published are mostly caches published for events where a lot (100+ ) listings are created over a period of time and caches are published in the evening on the date of the event. The hidden date isn't even the date the cache is hidden because that may well be the day before the event. Hidden date = listing created date.

More accurately: default hidden date = listing started date.

 

The "hidden date" is editable (with restrictions), so the cache owner usually is free to set it to set it to the date they hid the container, if that's what they want and if the reviewer allows it. I once hid the container months before I submitted my listing for publication, but the reviewer asked me to change it to a more recent date.

Link to comment
I once hid the container months before I submitted my listing for publication, but the reviewer asked me to change it to a more recent date.
I've found caches that were hidden more than a year before they were eventually listed on the geocaching.com site, and the "hidden date" reflected the date they were actually hidden--not the date they were published, and not the date the listings were originally created. IMHO, that is the right way to do it. The "hidden date" field reflected the date the caches were originally hidden.
Link to comment

It's a "Ship of Theseus" paradox (aka George Washington's axe).

Wikipedia

 

I always think the same of a football club. In 1890 a club existed and the "same" club continues today, even though every single player has changed, also the owner, all of the stadium (the location of which may even have been moved) and by now all the fans. Even the name might be changed. But it's still the same club.

 

Assuming that the physical cache was actually hidden on the Hidden Date, I don't see why it can't be regarded as the same cache, until the listing is archived.

Edited by Happy Humphrey
Link to comment

I have occasionally seen the Date Hidden be purposefully backdated. An old cache was archived, but the original container was found to still be in place, but abandoned (CO died, moved, or stopped caching). Thus another cacher published a new cache listing at the same location with the same container, and set Date Hidden to match an earlier listing.

 

Of course, this does raise some questions when determining the oldest cache in an area. Does the Publication Date determine oldest, Date Hidden, or something else?

Link to comment

I've seen it backdated in an apparent attempt at humor. For a while, the "oldest cache" in Germany was one of three multi caches that were obviously hidden in 2004 from the logs but were for some reason backdated much earlier. Then for a while it was one that was listed as being hidden in 1900, simply because it could be. I think enough people complained about tomfoolery that Groundspeak cracked down on how much you could fudge the date.

Link to comment

That's why it makes more sense to have "published date" instead (or added) to PQs. I don't really care for the hidden date (except when going for an old cache) but there seems to be no way to get a PQ with newly published caches.

 

As the Reviewers can Publish dozens of caches in one session, I'd rather have the 'Hidden' date. It does spread caches out a little.

It's already getting to the point of 'Date Placed' PQ's being 10-20-30 caches short of 1,000.

Imaging if it was set to 'Date Published' :o

Cachers would be asking for larger PQs! :rolleyes:

 

But. I'd prefer that the date for 'Date Placed' was set to the date of starting the listing, and was only editable (and only newer, not older) up to the date of review, at which point it became 'locked' and no change -backwards or forwards- allowed.

 

Published Date added to, yes, I agree. :)

Link to comment

 

As the Reviewers can Publish dozens of caches in one session, I'd rather have the 'Hidden' date. It does spread caches out a little.

It's already getting to the point of 'Date Placed' PQ's being 10-20-30 caches short of 1,000.

 

That's what's happening now with the placed date.

Example: I have PQ's covering Belgium (25000+ unfound) with a maximum of 995 caches/PQ selected by placed date. There are 27 PQs and if new caches would have a placed date = published date I would only have to keep an eye on PQ 27 filling up. Now, with the hidden date, PQ 23 can suddenly have an extra 20, 30,...70 caches so it exceeds the 1000 maximum. That means PQ 23 and later need to be edited.

Of course, the fact that PQ23 is "overflowing" is only noticed at the time it already ran and gets imported in GSAK where it's flagged in red.

 

Imaging if it was set to 'Date Published' :o

Cachers would be asking for larger PQs! :rolleyes:

 

I don't see how you would end up with >1000 PQ using Published instead of placed

Link to comment

But someone who finds the replacement is not finding the cache I hid in 2008, even though the cache page says it is a 2008 cache.

 

Yes they are. They're not finding the same container, that's all.

A cache is not simply the container... it is the whole experience.

The listing, the history of the location and scenery... even the logs on the cache since the beginning are part of it.

 

Even the owner changes in 8 years... I did. :)

 

While I as the OP appreciate all the commentary, this really says it all. I can go about caching fully satisfied.

Link to comment

Of course, the fact that PQ23 is "overflowing" is only noticed at the time it already ran and gets imported in GSAK where it's flagged in red.

You can submit a PQ for on-site review only (as often as you like). If it doesn't overflow on-site, then you can submit it again to generate a .GPX file.

 

I'm not going to check all PQs before running them. I run them on a weekly basis, a little after 9 in the morning (Seattle midnight) I get an email they are ready at which point GSAK imports them. That's when I notice the overflow, i.e. 1000+

What's the point in automating if you have to manually check first?

Link to comment

I look at "Your Pocket Queries Ready for Download". It tells me the number of GPX files in each pocket query. If the number in the most recent files is too high, I know to rework them. aNJ-13 is at 425, so I'm good for a while. It should not be a problem when it runs tomorrow.

 

Yes, but since don't want to check my PQs every week. Only the last PQ should be edited when it fills up. It's not normal to have to check the last 5-6 PQs just in case caches get published with hidden dates months ago. The point of PQs and the option to run them automatically is to be able to run them unattended without the need for constant maintenance.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...