the Seagnoid

When you log your find or discover a trackable, the default log date is the server date, which is (I think) Seattle server time. In New Zealand, where I live, the default date is correct in the latter part of the evening, but for most of the day the default date is yesterday - The US lives on the other side of the International Date line, almost a day behind us. I have to remember to add one to the date when I post my logs. Okay, I'm used to it, it is not a big deal. The site allows logs placed one day in the future, and saves the date (in a cookie?) so that any date I enter it is the default date for the next entry. So really it is only the first date per browser session that is annoying. And of course all this is relevant only when logging on the date I found the cache, but if we are going to be presented with a default date, it may as well be useful. There are a couple of better ways of handling that first date, where no date is saved in a cookie.. 1 Use Java to pick up the local system date. This would probably be the only thing that uses Java on the site, so maybe not such a good idea. The advantage of this is that if I am caching in a different country - different time zone, it would be correct. I vaguely recall that Java is problematic with phones? iphones? 2. Take the home user's home location Longitude position (east/west) divide it by 24 and approximate that as a timezone, and use this as an offset to the server time. There will still be date errors, but now they will only occur within an hour of midnight other than, as in my case, most of the day. This can all be processed at the server end, although it does require the user having their home location specified. Disadvantage here is that if I am caching in a different country, and logging the finds in that country, the date would still be based on the time in my home country. I would be happy with either option. Any chance of getting this added to the queue? thanks, Tom

I was expecting the GPS reading to be based on the centre of the zone, but it appears to use the edge. So I am going to use a slightly smaller zone and work off proximity instead. Thanks for your help guys!

I am not sure if this is a Urwigo problem, which is what I am using, or just a newbie error - this is my first Wherigo project. I have three problems. In the emulator they are fine, on my Garmin Oregon I get problems. My PC is vista if that makes a difference (apparently that is the reason Groundspeak's builder crashes): 1. Zone activate at 0m. I have range at 50m and proximity at 5m (they are small zones, approx 10m square). Active and visible are set. Any idea on where I might be going wrong? I was expecting the zone to activate at 5m out. 2. Zone commands do not appear on the Oregon. Are they supported on the Oregon? Show up and work fine in the emulator. 3. Can I get the Oregon to play a beep? I doubt it can handle a wav file! If there are instructions (click here, do this) please be precise, I am still finding my way around the interface! Thanks, Tom

I have quite a number of trackables out there, and luckily for me, the vast majority are still active (although one is buried under a landslide ). What I would like to see is a summary map showing all my trackables and their current locations. I envisage a concept pretty much like the current geocaching map, showing two different icons - one for a trackable in a cache, the other for a trackable being carried (location being where the most recent cache is). Hovering over the icon would produce a tooltip the trackable name, when clicked provide a balloon that shows the trackable name and its reference number (not the tracking ID), its icon, and maybe the cache name or person currently carrying it. Prev/next links as per the existing geocache map dialogs. Clicking on the TB name would take me to the TB's page. This could be implemented as an option on the existing geocaching map, or as a "Where are my trackables?" link on the Trackables - Yours page. If opening a new map page (such as the link option) the default zoom to show near enough whole world. If I only had one or two trackables out there this wouldn't be a problem, but with 53 active TBs out there (I try to launch one with each new cache), keeping tabs on them without going through them one at a time is a bit difficult. Thanks for your sterling work so far, GC team! Tom

Ahh. I'm getting old and my memory iis rusting. Thanks, Moun10bike. []

It used to be policy that you could not claim a find on your own caches. And when you attempted to, you got a warning from the website and it prevented you from continuing. This was because geocaching is about the challenge of the hunt - no challenge if you know where you put your cache! It is still policy but now the the website allows the finding of your own caches. Or is this a bug? I have noticed some geocachers logging finds on their own caches, probably some sad belief that geocaching is not about the adventure but just about the numbers. Tom

Yes, DanPan, that is exactly the list that needs to be on the profile page, thanks for the link to it. But as it stands now, it does not beep to remind me to look at it, so I still do not know if I have any that need fixing, and I have no need to go to this page unless I know that I have some that need fixing. I am certainly not going to look there every day on the off-chance that something has changed and I missed the email. I want cache owners to be EXPLICITLY reminded constantly that they have caches that need fixing. This means I will get them fixed faster, and provide a better experience for other cachers trying to find my caches. The banner on the profile page will do the job nicely.

[green] There is an easy way to tell an "ordinary" cache - lots of visits and no favorites. If you want to avoid crappy caches then just visit the ones with favs, and avoid the ones that need maintenance. I recently did a power trail of 101 caches. Worst caching experience I have ever had. Lack of maintenance, maintenance resulting in cache descriptions being inaccurate, nowhere to park so car has to stay two thirds into the the 100km/h lane. Needless to say, no favorites. And lots of comments, and lots of needs maintenance.

The email is, as was said earlier, just an email of the log. I agree with the original request, I would like to see the cache owner. This is easily fixed, but does have side affects. I realise that treating publish logs differently is a bit clumsy. The solution is to add the cache owner name to emailed logs. The main side affect is that found logs will tell me that someone found my cache x, which is owned by me - rather redundant I know it is my cache. However it may also help others who have watches on caches. If we can tolerate having the owner stated on find logs that are emailed to the owner, then this problem with publish logs will also be solved. Tom

Changed the browser icon to a green theme (matching the new banner). Icons for http://forums.Groundspeak.com and http://blog.geocaching.com/ not updated.

Yes I agree with this. A email notification that a image has been posted and an email log when a log is edited. Yes Please! Currently I do it the other way, in my log I state that I have uploaded a photo. But an automated email would be better. It doesn't need to include the image. Just a link to the log that includes the image. Because images are uploaded after the fact, this will result in multiple logs, but I see no way around that unless GS implements a 1/2 hour delay on emails, just in case photos are uploaded.

Nope pocket queries do not work. Most of the time the pocket query will be empty, and an email is still sent even if there are no results. The last think I want to do is spam myself with useless data. The one time there is something interesting it will get discarded as per habit. It needs to be an exception report (ie give no report at all if there is nothing there) and in your face as a constant reminder.

Yes, a pocket query works but is cludgy. Why grab a GPX from an email and have to load it into something to see what it contains, when Groundspeak actively promote that cachers do maintenance but give little tools to identify what caches need meintenance? Especially when they already provide EXACTLY what is needed, as a warning when you start work on publishing a new cache. Just take that query and data and present it on the profile page.

Dammit, I just re-discovered a cache I had disabled (got washed away in a flood) two weeks ago. PLEASE implement this!!

This is probably almost a bug now While at a Mega I found 10 lab caches and had a lot of fun. My profile page is updated with the finds and it all looks good. My statistics page does not look good. My cache count in the geocaching banner shows 2644 finds, my statistics page shows 2634 finds. I appreciate that these lab caches are development caches of a sort, but if there is an icon and count facility for the profile page then there should be no reason why the statistics page cannot be updated to reflect this too. Bits that need updating: Your Caching Chronology with the correct count, Cache Types I've Found with a new cache type. Container Types for lab caches should probably be set to <not chosen>. Terrain and difficulty is a problem, perhaps the defaults? <1.5/1.5>.

Just had another New Zealand geocacher test this - his is fine, so not a Groundspeak bug. Maybe a bug with a version of Java or something else. Cancel this bug report, thanks!

For about a month now (i.e. before the recent site maintenance) New Zealand switched to daylight savings time, GMT+13. Now, when I click the "Update my Statistics Now" button it updates the statistics correctly but reports that the statistics were last updated 12 hours ago. Prior to this it reported "less than a minute ago". This is confirmed on two different versions of firefox and on IE, on three different computers, with two different geocaching users. I have confirmed my profile settings are still set for New Zealand time, and that my computer time is correct. Can that text not handle GMT+13 and is the +13 hours causing a rollover effect?

Once the email advising me that a cache needs maintenance is gone, it can be very hard to work out which cache it was. It would be nice to have a summary list of caches that need maintenance, listed in Profile:Quickiew, just above the summary list of Your Unpublished Disabled Caches. This would result in them being constantly highlighted to the cache owner (me), which means I won't forget them and they will get maintained faster, thus improving the caching experience for those that hunt for it. I have just noticed I have a cache that has needed maintenance for over a month! Normally I fix them within a week. Which others of mine need maintenance? I don't know. Thanks guys, Tom

Project-gc.gom is brilliant. Thanks for your help, guys. Tom.

While I appreciate that there is sometimes a need to have a duplicate find on a cache, for many of us there is no valid reason - except an accident. For instance I am trying to help a cacher that has 999 finds, of which 8 are duplicates. And the only way I can find them is to troll through all 999 logs, copy each cache name or ID to another file, then sort it. EXTREMELY laborious. Could Groundspeak have a place to find duplicates (eg a "find duplicates" link on the statistic page where it says where it says "You've found xxx caches (xxy distinct)". This would list caches for which I have duplicates finds, and preferably provide links to the logs themselves. Also useful would be a "You have already logged a found on this cache" warning at the cache log creation page. Hopefully this will keep happy those who feel a need to record multiple finds, and also help those for who multiple finds counts are anathema. This is a very hotly contested topic over the years - something needs to be done in this area. The Seagnoid

Further to my efforts art resolving doubled up logs to get my cache count correct, I found a reporting bug on the geocaching.com website. Click Your profile / QuickView / geocaches / list caches you Have found. The report lists something like "Total Records: 67 - Page: 1 of 4 - < Prev << <[1 2 3 4]> >> Next > " However when adding up the records they do not match the total specified (in this case it shows 62). Yes, this is because of multiple Found logs, but in this case the page directly implies all logs are included. (This Example is from Fiz $ Tas public prifile, geocaches / traditional cache. I am helping her resolve her doubleups) Could the site be corrected so that when it says 67 records, it actually lists all 67 records. And if possible somewhere somehow have an option to list caches that have doubled entries. Everyone I know in my area does not like the distorted figures accidental doubled found entries causes, and resolving them can be difficult. Thanks, The Seagnoid

A minor bug - if too much text is added to a trackable description the page correctly alerts the problem and advises that only 10,000 characters are allowed. It also advises that there is too much text in the mission statement, even though the mission text is well under the limit.

Hmmm... looks like I have to learn GSAK...

By the way, I don't have any at the moment - had one yesterday that prompted this, but managed to work out which one it was.

Is there an easy way to identify which caches I have reported multiple finds on? While I understand that there were some caches that moved, and cachers were invited to refind them, resulting in the x finds on y unique caches, there are none in my home country and I do not want to sully my find count. Once identified I can easily delete the rogue log. It is the finding that is the problem. Thanks,