Jump to content

Adventure Lab Cache Time Stamp Error


TwigNZ

Recommended Posts

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 by TwigNZ
  • Upvote 3
  • Funny 1
  • Helpful 2
Link to comment
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.

  • Surprised 1
Link to comment
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!

Link to comment
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!

Link to comment
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?

Link to comment
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...

image.png.22c9c2feeda4baea4684171e1a31eccd.png

 

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!!

  • Surprised 1
Link to comment
12 hours ago, CAVinoGal said:

Project GC shows my lab caches as also spanning 2 days...

image.png.22c9c2feeda4baea4684171e1a31eccd.png

 

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.

Link to comment
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.

Link to comment

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 by caverdon
  • Upvote 2
Link to comment

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.

  • Upvote 5
  • Helpful 2
Link to comment

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?

  • Surprised 1
Link to comment

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!

  • Upvote 1
Link to comment
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. 

  • Upvote 2
Link to comment

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

  • Upvote 1
Link to comment

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. 

  • Upvote 3
Link to comment
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.

Lab Cache example.png

Link to comment
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.

Link to comment
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.

  • Upvote 2
  • Funny 1
  • Helpful 1
Link to comment

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!     

Link to comment

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!

Link to comment
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 :(

  • Upvote 1
  • Funny 1
Link to comment
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.

Link to comment

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.

Link to comment

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!

Grub Fred.jpg

Grub Fred.png

  • Funny 2
  • Helpful 1
Link to comment

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.

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...