"Found by user" - please use dates!

[+Run Amok]

I really, really, really wish the "found by user" column showed actual dates instead of "4 days ago", "3 days ago", etc. Trying to figure out if it's the same time zone or which day is really annoying to me. Does anyone have a reason to know how many days rather than a date? 

[+dprovan]

Well, of course I'm speculating, but from my experience with user interface design, the developer thought it was more "user friendly". And it is mor euser friendly when the user looking at the list is most interested in how many days ago.

 

What that interface doesn't consider is that sometimes one is looking for a specific date, not how long ago it was, and the "N days ago" defeats that. Worse, it means the column has two different values: it's easy to see that 4/10/2019 and 4/9/2019 are a day apart, but if I look at a list right now, I'll see "7 days ago" and 4/9/2019, and it's quite a hassle to figure out that those are two consecutive days.

 

Ideally the interface should be switchable to which ever I want at the time, but if it can't be under the user's control, my vote would be for a date. I find it relatively easy to convert "april 15th" to two days ago when that's what I'm interested in, but it takes a mental calculation for me to go the other way.

[+rapotek]

I totally agree with 'N days ago' switch to exact date and vice versa but there should be included (or clearly unified) a time zone too. If not, there is a possibility to see on the list a valid log entry with tomorrow's date.

[+Lynx Humble]

I would also like the option to have the exact date displayed. 

[Keystone]

I moved this thread from the general Geocaching Topics forum, since it's a feature suggestion. 

 

I think it's been this way since I started playing in 2002.

[+Isonzo Karst]

13 minutes ago, Keystone said:

I think it's been this way since I started playing in 2002. 

 

I think it's been that way since you started playing in 2002,  as it's been that since I started playing in 2003. And it's been annoying the whole time. ;-) 

I'd prefer log date.

[+hzoi]

2 hours ago, Isonzo Karst said:

3 hours ago, Keystone said:

I think it's been this way since I started playing in 2002. 

 

I think it's been that way since you started playing in 2002,  as it's been that since I started playing in 2003. And it's been annoying the whole time. ;-) 

I'd prefer log date.

 

It has definitely not changed since I started (he confirmed needlessly). 

 

I never really thought about it, but I'd be fine with a change.

[+NYPaddleCacher]

On 4/18/2019 at 2:42 AM, dprovan said:

Well, of course I'm speculating, but from my experience with user interface design, the developer thought it was more "user friendly". And it is mor euser friendly when the user looking at the list is most interested in how many days ago.

 

What that interface doesn't consider is that sometimes one is looking for a specific date, not how long ago it was, and the "N days ago" defeats that. Worse, it means the column has two different values: it's easy to see that 4/10/2019 and 4/9/2019 are a day apart,

 

Unless you're outside of the U.S., where those dates are typically read as a month apart.   It most of the world the date format is Day/Month/Year rather than Month/Day/Year.

 

[+rapotek]

28 minutes ago, NYPaddleCacher said:

 

Unless you're outside of the U.S., where those dates are typically read as a month apart.   It most of the world the date format is Day/Month/Year rather than Month/Day/Year.

 

The most uniform format would be Year/Month/Day then. With four digits in year to be more specific.

 

What I miss sometimes is a time of cache logging (hours and minutes) apart from the date itself, but I do not expect to see this functionality soon.

[+noncentric]

11 hours ago, rapotek said:

What I miss sometimes is a time of cache logging (hours and minutes) apart from the date itself, but I do not expect to see this functionality soon.

What do you envision for "time of cache logging".  Almost all of my caches are logs days/weeks after the actual find.  I use the correct find date in those logs, but I'm not going to enter a specific time.  If cachers want to include the time in their log text, then there are 3rd party tools that can do that.

[+rapotek]

2 hours ago, noncentric said:

What do you envision for "time of cache logging".  Almost all of my caches are logs days/weeks after the actual find.  I use the correct find date in those logs, but I'm not going to enter a specific time.  If cachers want to include the time in their log text, then there are 3rd party tools that can do that.

Mine sometimes too, not weeks but days after. But I try to note down an exact or approximate time of found or DNF for my own information.

Anyway I have faced the situation not once where there are a 'Found it' and a few DNFs logged with the same date. A cache was found earlier but the fact was logged later than DNFs, so the last entry is 'Found it' instead of DNF and it is not correct information for next seekers. The more detailed timing could help in keeping the right chronology.

[+on4bam]

3 hours ago, noncentric said:

What do you envision for "time of cache logging".  Almost all of my caches are logs days/weeks after the actual find.  I use the correct find date in those logs, but I'm not going to enter a specific time.  If cachers want to include the time in their log text, then there are 3rd party tools that can do that.

 

The time is already known if using a GPS, GDAK also stores the time in geocache_visits.txt file. It's then easy to include date/time in the logs. I do this since GSAK made tags available for logging via API.

[+noncentric]

36 minutes ago, rapotek said:

Mine sometimes too, not weeks but days after. But I try to note down an exact or approximate time of found or DNF for my own information.

Anyway I have faced the situation not once where there are a 'Found it' and a few DNFs logged with the same date. A cache was found earlier but the fact was logged later than DNFs, so the last entry is 'Found it' instead of DNF and it is not correct information for next seekers. The more detailed timing could help in keeping the right chronology.

So you want to rely on finders, and did-not-finders, to remember what time it was.  If they do not remember what time it was, then where do you think their log should be - before or after the other logs on that date that do have a time?  Personally,  I'm not convinced that the benefits of having the time attached to the log outweigh the development effort required.

 

 

11 minutes ago, on4bam said:

The time is already known if using a GPS, GDAK also stores the time in geocache_visits.txt file. It's then easy to include date/time in the logs. I do this since GSAK made tags available for logging via API.

Yes, the time is recorded in Drafts - whether those drafts are saved via a GPSr or the official app.  But not everyone saves their drafts at the time of their find.

 -- Some might go through and create multiple drafts after their hike, so their finds would look like they are minutes apart, even though they were spread out across several hours.  There would need to be an option to adjust the time.

 -- Some might suddenly remember that they forgot to log a find from a couple days ago and create a draft saying "found on Tuesday" so the cache shows in their Drafts list and they don't forget to log it later. They easily adjust the date of the find when submitting the log via the Drafts page, so then they'd need to also adjust the time.

 -- Some don't even use Drafts and log their caches using the "Log geocache" button on individual cache pages.  If there is a time selection on the logging page, then that opens up the can of worms related to time zones.

 

Plenty of cachers will not record the correct time and/or won't bother adjusting a newly added time field.  Bad data vs No data.  There would need to be an option to not populate time, so then the question becomes how those logs with blank time are sorted compared to other finds on the same date.  Doesn't really seem worth it to me.

[+rapotek]

13 minutes ago, noncentric said:

So you want to rely on finders, and did-not-finders, to remember what time it was.  If they do not remember what time it was, then where do you think their log should be - before or after the other logs on that date that do have a time?  Personally,  I'm not convinced that the benefits of having the time attached to the log outweigh the development effort required.

 

Plenty of cachers will not record the correct time and/or won't bother adjusting a newly added time field.  Bad data vs No data.  There would need to be an option to not populate time, so then the question becomes how those logs with blank time are sorted compared to other finds on the same date.  Doesn't really seem worth it to me.

If time is not needed, why to log a date at all? The single fact of 'Found it' or DNF etc. should be enough whenever it was logged, shouldn't it? ? It is only a matter of scale.

 

I geocache sometimes in an alternate system where hours and minutes are sent along with a date of log. I always try to submit the correct time, most often rounded to 5 minutes, and I suspect that I am in minority in that. But there are entries from other users with more or less correct times and they helped me a few times.

[+noncentric]

33 minutes ago, rapotek said:

If time is not needed, why to log a date at all? The single fact of 'Found it' or DNF etc. should be enough whenever it was logged, shouldn't it? ? It is only a matter of scale.

Considering that many caches are not found more than once a day, then just the date alone is sufficient for most.
 

 

33 minutes ago, rapotek said:

I geocache sometimes in an alternate system where hours and minutes are sent along with a date of log. I always try to submit the correct time, most often rounded to 5 minutes, and I suspect that I am in minority in that. But there are entries from other users with more or less correct times and they helped me a few times.

Cachers can certainly include the time in their logs.  I do for FTF's, as I think other cachers like to know how close/far they were to also getting the FTF.  But otherwise, I don't usually include the time unless it's somehow relevant to the hide, like open hours or busy muggle times.

[+on4bam]

1 minute ago, noncentric said:

Considering that many caches are not found more than once a day, then just the date alone is sufficient for most.

 

That may be true in your neck of the woods but...

Multi's and other caches that require some effort.. probably true.

Geo-art, easy series/trads... nope... especially during weekends with nice weather... nope... several logs per day.

 

[+noncentric]

7 hours ago, on4bam said:

That may be true in your neck of the woods but...

Multi's and other caches that require some effort.. probably true.

Geo-art, easy series/trads... nope... especially during weekends with nice weather... nope... several logs per day.

 

Seems like most of the times that caches are found by multiple cachers in a day, then they are cachers that are caching together - so the times would be pretty close.  Not sure what the benefit is of having the time be a field in the log entry. Cachers can certainly include the time of their find in their log text if they want to.

 

And yes, there are certainly some caches in my "neck of the woods" that are found more than once a day - but it doesn't seem to be typical, especially not the case the OP mentioned about a Found It and DNF on the same day.  And I'd wager that most of the days that caches are found, across the entire globe, have only one Found It being logged.  Again, it's a question of whether the benefit of the feature would outweigh the cost. Personally, I don't think it does.  YMMV.

[+CAVinoGal]

On 4/18/2019 at 8:30 AM, hzoi said:

I never really thought about it, but I'd be fine with a change.

 

Back the the topic at hand ... I, too, never gave it a thought - just saw that's how it was presented.  And sometimes I'll go to my list of finds, scroll back to those I found a few months ago, or on a trip somewhere, and see which ones have "2 days ago" or "4 days ago" - relatively recent finds vs logs closer to my Find date.  It's easy to see the "X days ago" text vs the date comparison.  It's not a major consideration either way for me - and it works just fine as it is, and apparently has been since the beginning.  

 

As far as a time stamp - I typically add the time to my log.  Following the example of my son and daughter in law, who put the FInd #, date and time on every log via their logging software, it'sjust how I like to do it.  But I do it manually - I note the time (nearest 5 minutes usually) in my Draft, then add Find # and who I was with when I write the actual log on my computer later.  I don't have a huge # of finds in a day, and usually log that same day, just not at the moment of the find (I make too many typos on my phone!!).  I don't log a time on an event, as it spans 30 minutes to hours - but I do try to add it to a regular cache "Found it" log.  But since my actual log is later, and some I know log weeks later - exact time would be problematic, and doesn't add that much information overall.  A year from now, does it make a difference if I found it at 10:00 or 14:00??  Probably not.

[+thebruce0]

On 4/18/2019 at 11:30 AM, hzoi said:

On 4/18/2019 at 8:45 AM, Isonzo Karst said:

On 4/18/2019 at 8:29 AM, Keystone said:

I think it's been this way since I started playing in 2002. 

 

I think it's been that way since you started playing in 2002,  as it's been that since I started playing in 2003. And it's been annoying the whole time. ?

I'd prefer log date.

 

It has definitely not changed since I started (he confirmed needlessly). 

 

I never really thought about it, but I'd be fine with a change.

 

I shall also confirm needlessly as it's been this way since I began in 2009. 

 

 

On 4/27/2019 at 3:55 AM, noncentric said:

-- Some might go through and create multiple drafts after their hike, so their finds would look like they are minutes apart, even though they were spread out across several hours.  There would need to be an option to adjust the time.

 

Geosphere has the option to adjust the date/time for the in-app notes (as does Cachly), which when uploaded and posted immediately from the app are stored with the logs and the proper timezone -- but when uploaded to drafts first the app still 'fixes' the old timezone bug so the drafts page could drop the composed log to the next day.  I now just avoid posted field notes from Geosphere (since both Geosphere and Cachly can post logs live; I'll use Cachly if I really want to just post drafts for later).  Kind of confusing I wish Mark would return. *sigh*