Jump to content
Sign in to follow this  
Followers 8
TwigNZ

Adventure Lab Cache Time Stamp Error

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
  • Helpful 1

Share this post


Link to post

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

 

  • Funny 1
  • Surprised 1

Share this post


Link to post

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 by whwt
  • Upvote 1

Share this post


Link to post

I saw somewhere that all AL finds were processed on Seattle time/date - with no allowance for your local time zone/date.

Share this post


Link to post
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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
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

Share this post


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

Share this post


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

Share this post


Link to post

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.

  • Upvote 1

Share this post


Link to post

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

Share this post


Link to post

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

  • Surprised 1
  • Helpful 1

Share this post


Link to post

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 4
  • Helpful 2

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post
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

Share this post


Link to post

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.

  • Upvote 1

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post
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

Share this post


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

Share this post


Link to post
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
  • Helpful 1

Share this post


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

 

Share this post


Link to post

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!     

Share this post


Link to post

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. 

  • Upvote 1

Share this post


Link to post

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!

Share this post


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

  • Funny 1

Share this post


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

Share this post


Link to post

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...
Sign in to follow this  
Followers 8

×
×
  • Create New...