+TwigNZ Posted March 1, 2020 Share Posted March 1, 2020 (edited) I initially raised the issue of the erroneous Time Stamping of Lab Caches back in November, and received no acknowledgment or reply from site Admin. I then asked for some kind of response a couple of weeks later, and had my thread shut down. Well I guess that was a response huh? So now a further 3 months or so has passed. Is there any update as to when we can possible expect the issue of Lab Caches being time stamped on Geocaching.com based solely on Seattle time to be dealt with? Or even if there are any plans to deal with it? Is it even being looked into? Any news at all would be good here guys. Edited March 1, 2020 by TwigNZ 3 1 2 Quote Link to comment
+lee737 Posted March 2, 2020 Share Posted March 2, 2020 Use it your advantage, it makes it easy to log caches on the day befores date.... handy for your date-found grid, and since it is out of your control.... nobody could accuse you of being creative with your log dates.... 1 1 Quote Link to comment
+whwt Posted March 2, 2020 Share Posted March 2, 2020 (edited) Maybe that`s the reason i did not get the leap day souvenir, we logged some adventure lab caches, which i think should count for the souvenir. We are from Europe. Edited March 2, 2020 by whwt 1 Quote Link to comment
+K13 Posted March 2, 2020 Share Posted March 2, 2020 I saw somewhere that all AL finds were processed on Seattle time/date - with no allowance for your local time zone/date. Quote Link to comment
+CAVinoGal Posted March 3, 2020 Share Posted March 3, 2020 5 hours ago, K13 said: I saw somewhere that all AL finds were processed on Seattle time/date - with no allowance for your local time zone/date. I'm in the same time zone as Seattle; twice I've had labs span over two days, when we did them in one afternoon. (One was on 12/23/19; lab dates show 12/23/ and 12/24.) The other as done on 12/30/19, but logged as 12/30 and 12/31, giving me the 3-2-1 AND the Good bye 2019 souvenirs on 12/30/19, even though I hadn't yet earned either one of them. I DID find a cache on 12/31/19 to earn the souvenirs "legitimately", but both show on my profile as having been earned on 12/30/19. The timestamp seems to be (In my case) GMT. I've posted screenshots on other threads of this discrepancy. 1 Quote Link to comment
+TwigNZ Posted March 3, 2020 Author Share Posted March 3, 2020 16 hours ago, lee737 said: Use it your advantage, it makes it easy to log caches on the day befores date.... handy for your date-found grid, and since it is out of your control.... nobody could accuse you of being creative with your log dates.... Hi Lee. But it is not to my advantage, as Project GC manages to correctly and accurately Time Stamp AdLab caches, so with this glitch you suddenly get a discrepancy between the two sites for the same stats. Plus, and I guess it's a personal thing, but I don't want to use a glitch (even inadvertently) to fill in dot days. Right now my GC stats show that I got 5 caches on November 14th last year which was a Dot Day for me, but I actually got those AdLab caches on November 15th as recorded (accurately) on Project GC. So for a year I will have non-matching stats between the 2 sites, assuming I am able to find a real cache on Nov 14th this year to genuinely deal to that Dot Day. It's just frustrating that we are getting no information on what, if anything, is being done about this problem! Quote Link to comment
+TwigNZ Posted March 3, 2020 Author Share Posted March 3, 2020 8 minutes ago, CAVinoGal said: I'm in the same time zone as Seattle; twice I've had labs span over two days, when we did them in one afternoon. (One was on 12/23/19; lab dates show 12/23/ and 12/24.) The other as done on 12/30/19, but logged as 12/30 and 12/31, giving me the 3-2-1 AND the Good bye 2019 souvenirs on 12/30/19, even though I hadn't yet earned either one of them. I DID find a cache on 12/31/19 to earn the souvenirs "legitimately", but both show on my profile as having been earned on 12/30/19. The timestamp seems to be (In my case) GMT. I've posted screenshots on other threads of this discrepancy. That's pretty random! I'm in New Zealand and have done 5 different Adventure Labs so far, and every single one of them have time stamped according to Seattle time! The first 2 have got my finds on the wrong date, but then I spotted what was going on and made sure I did my logging in the 3 hour window (9pm to midnight) to make things happen correctly. It's manageable, but a pain in the $%#@ when it interferes with Dot Days! Quote Link to comment
+TwigNZ Posted March 3, 2020 Author Share Posted March 3, 2020 15 hours ago, whwt said: Maybe that`s the reason i did not get the leap day souvenir, we logged some adventure lab caches, which i think should count for the souvenir. We are from Europe. That might be the issue, especially if you did yours in the morning whilst it was still Feb 28th in Seattle? Quote Link to comment
+CAVinoGal Posted March 3, 2020 Share Posted March 3, 2020 32 minutes ago, TwigNZ said: Project GC manages to correctly and accurately Time Stamp AdLab caches, Project GC shows my lab caches as also spanning 2 days... And my souvenirs seemed to have corrected themselves - Goodbye no longer shows 12/30/19 but the correct date of 12/31/19; however my 3-2-1 shows I earned it 12/30/19 when in reality, my 6th caching days of the period was 12/31/19. Strange, but in the overall scheme of things, just a nit pick for those of us who like our stats to be accurate!! 1 Quote Link to comment
+TwigNZ Posted March 3, 2020 Author Share Posted March 3, 2020 12 hours ago, CAVinoGal said: Project GC shows my lab caches as also spanning 2 days... And my souvenirs seemed to have corrected themselves - Goodbye no longer shows 12/30/19 but the correct date of 12/31/19; however my 3-2-1 shows I earned it 12/30/19 when in reality, my 6th caching days of the period was 12/31/19. Strange, but in the overall scheme of things, just a nit pick for those of us who like our stats to be accurate!! Talking of souvenirs made me go and take a look at mine. I apparently acquired the latest Leap Day 2020 one on the 1st March, and the Fun in all Directions one on Feb 3rd lol! Looks like those get time stamped from when you post your log for the qualifying cache. I can see why that happens, but it does make the souvenirs look a bit daft. Quote Link to comment
+CAVinoGal Posted March 3, 2020 Share Posted March 3, 2020 1 hour ago, TwigNZ said: Talking of souvenirs made me go and take a look at mine. I took a look at dates - wow are they a bit messed up!! Here's the ones I noticed: Last cache of 2017 - earned 1/1/2018 First of 2018 is correct, 1/1/2018 Thanks 2018 - earned 1/1/2019 Hello 2019 - earned 1/2/2019 Goodbye 2019 is correct, 12/31/2019 Hello 2020 - earned 1/2/2020 Fun in All Directions - earned 2/3/2020 But all this is off topic fromt he Adventure Lab timestamps, which seems to also be a day off here and there. Wow. Quote Link to comment
+igator210 Posted March 4, 2020 Share Posted March 4, 2020 I have a couple of Lab Caches that have the incorrect date stamped. I emailed HQ about it and the reply was that currently there wasn't away to edit the date. 1 Quote Link to comment
+caverdon Posted March 4, 2020 Share Posted March 4, 2020 (edited) I also noticed this time-stamping problem with lab caches. I found 4 lab caches late on leap day (Feb 29), expecting them to show up as such in my stats. I am in the southern U.S., Central time zone. However, they appear on Project-GC as being found on March 1. When I check the geocaching web site and look at the dates for those 4 lab caches, it says "March 1 UTC". But then when you look at the monthly stats page on the geocaching web site, the 4 lab caches are counted for February 29. So there is wrong reporting of lab cache date data in geocaching.com's own stats pages. Would love to get that corrected!!! I'm being cheated out of caches legitimately found on leap day. Edited March 4, 2020 by caverdon 2 Quote Link to comment
+alan666notb Posted March 6, 2020 Share Posted March 6, 2020 I have the same problem, raised it via a support Email and got this ... Hello Alan- Thank you for contacting Geocaching HQ. Unfortunately, it is currently not possible to adjust the timestamp on adventure lab logs. Best regards, Martin 1 1 Quote Link to comment
+The A-Team Posted March 6, 2020 Share Posted March 6, 2020 I recently encountered an issue where a Lab find didn't get correctly recorded in the database. In trying to sort this out, I deleted the finds that did work and then learned that you can't re-find them. When I reached out to HQ, they refused to rectify the issue, stating that Adventure Labs are "experimental" and basically giving themselves a convenient way of refusing to deal with any of the issues that have arisen from them. Let's be clear: they do have the ability to fix timestamps on Adventure Lab logs. It's their product storing data in their database, so they have the ability to make whatever changes are necessary to rectify an issue in the data. They've made a decision to not exercise that ability. In short, Adventure Labs are an experimental feature for which HQ will not provide support. Find them at your own risk. 5 2 Quote Link to comment
+zdonb Posted March 8, 2020 Share Posted March 8, 2020 Similar date found problem as above - I found 5 lab caches on Feb 29 late in the day (11:50ish p.m.) in Southern California, which is the same as Seattle time. They all showed up as 3/1/20 I saw someone complained to Project-GC, and Project-GC assigns the fault to geocaching.com. The activity log on that particular adventure shows it was logged as finished on 2/29/20, so why not the associated adventure lab caches? 1 Quote Link to comment
+TwigNZ Posted March 10, 2020 Author Share Posted March 10, 2020 Thank you to everyone who has contributed to this thread. So far the response from Groundspeak has been completely underwhelming. I see the issue as being two-fold; Firstly there is the issue of existing erroneous logging. So far Groundspeak are refusing to do anything about this. They state they simply aren't able to, which may or may not be true. I personally have no reason to doubt them on this but I am not in possession of all the facts behind what it would take to edit the existing time stamping. Secondly, and for me the more important issue, is stopping the same problem happening moving forward. I know correct time stamping IS possible as Project GC appear to accurately time stamp the AdLabs (or at least they have done so with all of mine) so if they can do it then why couldn't Groundspeak? This won't solve the issue of the existing bad timestamping, but it would prevent further frustration. The annoying thing is that there appears to be no word from those on high as to what, if anything, is currently being done about this issue. Please Groundspeak, can we have some form of official announcement on this issue? Are you working on it? Have you any intention of working on it? Some kind of timeframe for a fix if you are working on it? C'mon guys, throw us a bone here! 1 Quote Link to comment
+igator210 Posted March 10, 2020 Share Posted March 10, 2020 On 3/6/2020 at 4:02 PM, The A-Team said: I recently encountered an issue where a Lab find didn't get correctly recorded in the database. In trying to sort this out, I deleted the finds that did work and then learned that you can't re-find them. When I reached out to HQ, they refused to rectify the issue, stating that Adventure Labs are "experimental" and basically giving themselves a convenient way of refusing to deal with any of the issues that have arisen from them. Let's be clear: they do have the ability to fix timestamps on Adventure Lab logs. It's their product storing data in their database, so they have the ability to make whatever changes are necessary to rectify an issue in the data. They've made a decision to not exercise that ability. In short, Adventure Labs are an experimental feature for which HQ will not provide support. Find them at your own risk. I make my living maintaining and fix a database. I have so many questions regarding how Groundspeak stores AL caches. 2 Quote Link to comment
+Aussiebrian Posted March 18, 2020 Share Posted March 18, 2020 This used to be a problem a few years ago when all finds were logged in US Pacific time. When logging in Australia the days are incorrect. It has been updated for other caches so it would be good if this can be fixed as well. 1 Quote Link to comment
+riokun Posted March 20, 2020 Share Posted March 20, 2020 I would also like to see this issues (which was raised months ago) addressed. I had a gap in my 'find calendar' where I have never found a cache on 5 December 2019. So on 5 December 2019 I went and found the lab caches than run through the Sydney, Australia CBD. And now I find that the lab caches were all logged as found on 4 December, so I still have the gap in my calendar. At least with other caches you can choose the find date (for example if you are catching up on your logs) or change the date if you accidentally logged it wrong. However with lab caches there's no options re date/time/timezones, and due to the nature of the cache type you have to log them then and there. I do not like the idea of manipulating stats by finding lab caches the day after, or in theory finding two lab caches a few minutes apart that might count as being found on two different days. If I wanted to do that I might as well go back and change the dates on all my finds so I can (falsely) claim streaks, fill my calendar etc. Of course I won't do that, and this is not the behaviour I would like to see encouraged by any source. As stated above, Project GC manages to get this right, so why not Groundspeak - to whom many of us are paid customers? There should be an easy solution for this, eg allow the app to use the timezone for the current location / use the time&date of the phone's calendar / allow the user to confirm the date when logging / allow the dates to be adjusted within the app or on geocaching.com..... I would be nice if Groundspeak could at least provide a response saying they are aware of the issue and their rationale for it being a certain way. Thanks, John 1 Quote Link to comment
Frau Potter Posted April 8, 2020 Share Posted April 8, 2020 Thanks for your patience regarding the time stamp issue between Adventure Lab and Geocaching.com. We believe this issue is now resolved (for future Adventure Lab finds). The Adventure Lab find will now count towards the local time where the Adventure Lab is located. It should therefore record the correct date for your find with your Geocaching.com stats. 3 Quote Link to comment
+JanlarC Posted June 14, 2020 Share Posted June 14, 2020 On 4/8/2020 at 5:16 PM, Frau Potter said: Thanks for your patience regarding the time stamp issue between Adventure Lab and Geocaching.com. We believe this issue is now resolved (for future Adventure Lab finds). The Adventure Lab find will now count towards the local time where the Adventure Lab is located. It should therefore record the correct date for your find with your Geocaching.com stats. Thanks for fixing this. I logged two lab caches on June 3 at about 8 pm MDT in Lethbridge Alberta and they show up on the Geocaching.com calendar as being found on the correct date. However, when I go into my public profile, and click on lab caches, they show up using the UTC time, making the date June 4th. I apologize if this is not the place to comment on this, but shouldn't the date be consistent with the local time in both places? A challenge checker from Project-GC used the date that came from the public profile, rather than from the calendar, which made me ineligible for the challenge that I was working towards. Quote Link to comment
+CapJackSparrow Posted July 10, 2020 Share Posted July 10, 2020 On 4/9/2020 at 12:16 AM, Frau Potter said: Thanks for your patience regarding the time stamp issue between Adventure Lab and Geocaching.com. We believe this issue is now resolved (for future Adventure Lab finds). The Adventure Lab find will now count towards the local time where the Adventure Lab is located. It should therefore record the correct date for your find with your Geocaching.com stats. Despite the alleged "fix", I don't think this is fully working as expected yet. I just found 10 Adventure Lab caches today (10th July 2020) in the UK. All 10 appear with the correct date on the log page for Adventure Lab caches (https://labs.geocaching.com/logs) as "Completed: 07/10/2020 UTC". However, if I look at my geocaching statistics page (https://www.geocaching.com/my/statistics.aspx) and the calendar grid for "Finds for Each Day of the Year" I can see that the total finds for July 9 has been incremented by 8 and the total finds for July 10 has been incremented by 2. So 10 finds have been recorded in my statistics, but across 2 separate days. This is clearly a bug. What's going on? Can you please advise if this issue is going to be resolved properly? Given that one of the main requirements for playing the game is recording and logging finds on a specific date, it seems implausible that something as basic as storing the date electronically is not working correctly. As a software developer I am fully aware of the challenges that recording data from multiple different time zones can present. However, this is a well understood problem. To use a phrase ... "it is not rocket science". If anyone from Groundspeak wants to contact me then I am happy to go through the specific details of my bug report if required. Many thanks. Quote Link to comment
Frau Potter Posted July 10, 2020 Share Posted July 10, 2020 6 hours ago, CapJackSparrow said: Despite the alleged "fix", I don't think this is fully working as expected yet. I just found 10 Adventure Lab caches today (10th July 2020) in the UK. All 10 appear with the correct date on the log page for Adventure Lab caches (https://labs.geocaching.com/logs) as "Completed: 07/10/2020 UTC". However, if I look at my geocaching statistics page (https://www.geocaching.com/my/statistics.aspx) and the calendar grid for "Finds for Each Day of the Year" I can see that the total finds for July 9 has been incremented by 8 and the total finds for July 10 has been incremented by 2. So 10 finds have been recorded in my statistics, but across 2 separate days. This is clearly a bug. What's going on? Can you please advise if this issue is going to be resolved properly? Given that one of the main requirements for playing the game is recording and logging finds on a specific date, it seems implausible that something as basic as storing the date electronically is not working correctly. As a software developer I am fully aware of the challenges that recording data from multiple different time zones can present. However, this is a well understood problem. To use a phrase ... "it is not rocket science". If anyone from Groundspeak wants to contact me then I am happy to go through the specific details of my bug report if required. Many thanks. We are aware that the timezone update may not be working properly on all statistic functions. We will look into it. 2 1 1 Quote Link to comment
+CapJackSparrow Posted July 10, 2020 Share Posted July 10, 2020 3 hours ago, Frau Potter said: We are aware that the timezone update may not be working properly on all statistic functions. We will look into it. Thanks for the reply. Quote Link to comment
+ukkijaai Posted July 11, 2020 Share Posted July 11, 2020 I encountered same issue two days ago. July 9th I had previously 5 finds and I intended to increase the number to 10 by finding 5 Adventure Lab caches. Additionally I found two normal caches. The result was that now I have 8 finds for that day. What happened is that 2 normal caches were recorded properly but from 5 AL caches only one was recorded correctly and 4 to the previous date. Obviously that is somehow related to 10 hour time difference between Seattle and my country Finland (although I found AL caches around 1-2 am Seattle time). What is odd, however, is that https://labs.geocaching.com/logs lists all 5 AL finds properly! This means that geocaching.com has the correct data but statistics works incorrectly! I hope that bug will be fixed soon! Quote Link to comment
+igator210 Posted July 13, 2020 Share Posted July 13, 2020 I still wish there was a way to edit the date of past Lab Caches.If it has a Log date, it should be easily editable. 1 Quote Link to comment
+CapJackSparrow Posted July 24, 2020 Share Posted July 24, 2020 Just to add some further information that may help with diagnosing and/or fixing the problem. I have an account with project-gc.com and the numbers they quote on the "Finds by found date" calendar chart for the 9th/10th July are correct. It shows 13 caches for the 9th and also 13 caches for the 10th. For reference, the statistics on the "Finds for each day of the year" calendar chart on geocaching.com for 9th/10th July show 21 and 5 (i.e. a total of 8 Adventure Lab caches incorrectly showing against the 9th July). Hope that helps! Quote Link to comment
+TwigNZ Posted December 21, 2020 Author Share Posted December 21, 2020 On 4/9/2020 at 11:16 AM, Frau Potter said: Thanks for your patience regarding the time stamp issue between Adventure Lab and Geocaching.com. We believe this issue is now resolved (for future Adventure Lab finds). The Adventure Lab find will now count towards the local time where the Adventure Lab is located. It should therefore record the correct date for your find with your Geocaching.com stats. It's been a while since I last logged into this forum, but I've just seen this post. I'm sorry to say that some 8 months later this is still not true. All Adventure Labs are STILL being logged with PST timestamping. All that has happened recently is that Project GC have now aligned their time stamping to be the same as Groundspeak, so now BOTH organisations are synchronously wrong 1 1 Quote Link to comment
+The A-Team Posted December 22, 2020 Share Posted December 22, 2020 On 12/21/2020 at 12:53 PM, TwigNZ said: It's been a while since I last logged into this forum, but I've just seen this post. I'm sorry to say that some 8 months later this is still not true. All Adventure Labs are STILL being logged with PST timestamping. All that has happened recently is that Project GC have now aligned their time stamping to be the same as Groundspeak, so now BOTH organisations are synchronously wrong I agree with TwigNZ that there's still something off in places. I didn't realize that there was an issue until just recently, when I completed an Adventure from approximately 4:30 to 4:40 pm PST on November 29. This corresponds to around 00:30 UTC on November 30. The five finds were correctly added to November 29 on the Geocaching.com stats calendar. However, the app, labs.geocaching.com, and the API show me as finding them on November 30. My guess is that Project-GC is now using the API, and that the API isn't passing the correct time zone offset along with the UTC timestamp. Quote Link to comment
+Janus101 Posted February 22, 2021 Share Posted February 22, 2021 Unfortunately this issue is still not resolved. I am having an ongoing streak since November 15th 2020. But on some days, I found exclusively lab caches, the official statistic always shortens this streaks. When I compare the Finds for Each Day of the Year statistics on geocaching.com to gc project it clearly shows me, that the time counter of geocaching.com is wrong. Quote Link to comment
+Grub Fred Posted March 4, 2021 Share Posted March 4, 2021 Have I missed something? Shaneo58 pointed this out to me yesterday, it appears that the dates for Lab Cache finds have been changed. On 1st February 2020 Liz and Bruce, shaneo58 and I (Grub Fred) found the 5 sites of Picture Perfect Pillar People in Newcastle, NSW, Australia. Because of time differences with the USA, these were shown as finds on 31st January on our 366 day grids, but suddenly those finds have been changed to 2nd February. This has sure messed up those of us that are chasing fillings of the 366 day grid! I have now missed out on 3 days in Jan/Feb until next year and 4 days in Nov/Dec! 2 1 Quote Link to comment
+miaux Posted March 6, 2021 Share Posted March 6, 2021 Me, too! I have been filling in the dates with no finds this year, and doing a lot of labs (due to the publishing stop for new caches and less traveling due to Corona restrictions) and noticed that January 30th is empty again! I am very glad for the improvement, but annoyed that the rules of the game changed retroactively. 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.