Jump to content
Sign in to follow this  
Followers 13
Sir-Lancelot

Field Notes

Recommended Posts

Note also that I have no issues when uploading field notes directly from a GPS device, either.

Share this post


Link to post

I'd love to help you, but this seems to be an issue with GeoSphere and not Geocaching.com. When I submit a field note by other sources - Geocaching.com apps, Cachly, Looking4Cache tested so far - the field note is set to the correct time. Only GeoSphere seems to be bumping it ahead 8 hours.

 

Well this is where it's odd. Because the date is stored GMT, exported GMT, 8 hours isn't even the difference between me and GMT, uploading from the phone in another timezone made no difference, no timezone issue occurs when posting directly as a log, afaik the field note uploading isn't done via the API (it was a function provided before the API was integrated), nothing changed with the app when this started occurring, and I can't even think of a reason why 8 hours would be the difference in the first place, other than that it may be ignoring my timezone and assuming the upload timezone is HQ (Pacific), then converting to GMT.

 

8 hours being the difference between HQ and GMT seems to be a pretty telling sign.

 

Maybe there's a developer I can work with who can watch my data and find out where the disconnect lies. It's not just me. I don't know if it's just Geosphere. But I can't believe it's "just a problem with the app" when nothing changed. blink.gif

 

ETA: Additionally, EngPhil reported what seems to be some other timezone inconsistencies with his uploaded field notes.

Edited by thebruce0

Share this post


Link to post

My geocaching.com settings have timezone utc +1, but when i posted a fieldnote in the "old" original app at Norwegian date and time: desember 18 22:23.

the fieldnotes on geocaching.com puts the found date and time as: 19 December 2016 06:23:05

Edited by cghove

Share this post


Link to post

For cross-reference, this is also being discussed in the Geocaching iPhone App topic (thread)

That discussion is about an issue unrelated to field notes.

 

Since it only seems to be Geosphere that's still having issues with field notes, have you contacted the developers of that app about the issue? It seems likely that the root of the problem lies within that app, since all other apps seem to be working as expected, and they're all using the same API.

Share this post


Link to post

For cross-reference, this is also being discussed in the Geocaching iPhone App topic (thread)

That discussion is about an issue unrelated to field notes.

 

Since it only seems to be Geosphere that's still having issues with field notes, have you contacted the developers of that app about the issue? It seems likely that the root of the problem lies within that app, since all other apps seem to be working as expected, and they're all using the same API.

 

Nope, see a few posts up.

And yes there is a discussion on GS's forum (as linked a few posts up). Most apps have updated to use the API. What we need are additional (old) apps that still use the old method for submitting field notes to solidify where the issue seems to lie. Again, nothing changed in the app, but updates are pumped out at gc.com regularly, and so the weight lies heavily on the side of non-API Field Note submission according to the research I've done on the problem.

 

Per the other thread, yeah I don't know if it's the same specific issue now that I realize the OP didn't say they used field notes, but someone else brought up this issue over there :P oops. We'll find out soon.

 

What would be enlightening is if all those direct-logging datetime problems occur after 4pm local time (8 hours prior to local midnight roll-over). If so, then the +8 hour issue is actually not just related to (what I believe to be) the 'old' Field Notes submission function but may have its fingers in a number of legacy note/log submission functions.

Edited by thebruce0

Share this post


Link to post

For cross-reference, this is also being discussed in the Geocaching iPhone App topic (thread)

That discussion is about an issue unrelated to field notes.

 

Since it only seems to be Geosphere that's still having issues with field notes, have you contacted the developers of that app about the issue? It seems likely that the root of the problem lies within that app, since all other apps seem to be working as expected, and they're all using the same API.

I'm using the "old" original "payed" app from Groundspeak on my samsung android phone and have trouble with fieldnotes don't even have geosphere

Share this post


Link to post

I'm using the "old" original "payed" app from Groundspeak on my samsung android phone and have trouble with fieldnotes don't even have geosphere

Can you describe what you mean by "trouble"? Are you experiencing the same issue as thebruce0 where field notes have a time offset when uploaded to geocaching.com, or are you seeing some different problem? I just tested uploading a field note from the old paid app (now called "Geocaching Classic"), and it shows the correct time on the website.

Share this post


Link to post

I'm using the "old" original "payed" app from Groundspeak on my samsung android phone and have trouble with fieldnotes don't even have geosphere

Can you describe what you mean by "trouble"? Are you experiencing the same issue as thebruce0 where field notes have a time offset when uploaded to geocaching.com, or are you seeing some different problem? I just tested uploading a field note from the old paid app (now called "Geocaching Classic"), and it shows the correct time on the website.

My geocaching.com settings have timezone utc +1, but when i posted a fieldnote in the "old" original app at Norwegian date and time: desember 18 22:23.

the fieldnotes on geocaching.com puts the found date and time as: 19 December 2016 06:23:05

Share this post


Link to post

Still a [quite annoying] problem.

Edited by thebruce0

Share this post


Link to post

I just experienced the issue again tonight. All my settings at Groundspeak, and in my iPhone 6 (latest iOS) are all correct. All my field notes were +8 hours

Share this post


Link to post

I'd love to help you, but this seems to be an issue with GeoSphere and not Geocaching.com. When I submit a field note by other sources - Geocaching.com apps, Cachly, Looking4Cache tested so far - the field note is set to the correct time. Only GeoSphere seems to be bumping it ahead 8 hours.

 

The problem actually lasted about 1 week in early November.

I used field notes from a Garmin device and via the c:geo from my cell phone.

After "the Fix" from Groundspeak, it worked better.

I prefer to use GSAK after this happened because I don't trust that it won't recur. :-/

Share this post


Link to post

Not surprising from c:geo as it's not authorized and likely used the public non-api method of submitting field notes.

Can you link to "the fix"? I don't recall. It might shed some light. If that issue was 'fixed', it either wasn't the same issue, or it wasn't completely fixed =/

Share this post


Link to post

My geocaching.com settings have timezone utc +1, but when i posted a fieldnote in the "old" original app at Norwegian date and time: desember 18 22:23.

the fieldnotes on geocaching.com puts the found date and time as: 19 December 2016 06:23:05

Problem still here with the "old" Geocaching app from Groundspeak on my samsung galaxy s7(version 3.5.2)

Share this post


Link to post

I use a:Drake, I am in UTC + 1 timezone. I have just uploaded field notes from my yesterday's finds and all of them show times + 9 hours.

 

(for instance: a cache found in 9:25 displays with 18:25 now on the Field notes page on gc.com).

 

It was first reported within this thread on November 10. It should have gotten fixed within a week but we already have year 2017. Should I pay $60 instead of $30 to get this fixed? Or more?

Share this post


Link to post

For cross-reference, this is also being discussed in the Geocaching iPhone App topic (thread)

That discussion is about an issue unrelated to field notes.

 

Since it only seems to be Geosphere that's still having issues with field notes, have you contacted the developers of that app about the issue? It seems likely that the root of the problem lies within that app, since all other apps seem to be working as expected, and they're all using the same API.

 

The developer no longer seems interested in updating the app ... it's been wonderful but, sadly, it appears we'll need to find a new app to use.

Share this post


Link to post

Nope, that's conjecture.

The app will only die when it's no longer supported in the OS, and though it is nearing that point, the developer has never once stated that there would be no more development, but has chimed in on the rare occasion to admit the delay and say that a new version is being developed. You can choose to believe it's a lie, you can choose to believe that he's incompetent and won't actually follow through, but the base facts are he's only said he's still here and GS is basically still alive.

 

The gaps between updates are disconcerting, and many are slowly moving to other apps, but from my experiences with other apps, GS is still the most data-oriented and flexible caching app, while others are more powerful and usable for the activity of geocaching. So I'll still be using GS as long as it works, along with other apps that provide newer feature sets, and hold out hope that we'll be surprised by a major version release (or alpha/beta invite) in the somewhat near future. :)

 

ETA: But none of that has anything to do with the Field Notes issue, which has shown to exist beyond the Geosphere app.

Edited by thebruce0

Share this post


Link to post

I use a:Drake, I am in UTC + 1 timezone. I have just uploaded field notes from my yesterday's finds and all of them show times + 9 hours.

 

(for instance: a cache found in 9:25 displays with 18:25 now on the Field notes page on gc.com).

 

It was first reported within this thread on November 10. It should have gotten fixed within a week but we already have year 2017. Should I pay $60 instead of $30 to get this fixed? Or more?

 

The basic idea of API-solutions is to avoid future changes in the way the data is presented for applications. This idea got somehow broken few months ago. I waited a while for immediate fix and now there is more more unexpected changes in the way how corrected coordinates are presented in the API.

 

To fix the fieldnote timing problem, I changed my time zone from Finland to Canada :blink: (-8 hours). The corrected coordinates problem I can handle the same old way I was used before this feature was published to API years ago. You, at Groudspeak, have to break little more to make my long lived mobile app totally unusable.

Share this post


Link to post

huh, interesting trick. Yes, changing my profile timezone to -12 results (as one would expect) in Field notes at +1 hour (I'm at GMT-5, but there's no GMT-13).

However, while that's then only 1 hour off the actual time and easier to manage field notes, it only helps field notes, and everything else on the website is now off by the new offset, which can cause other problems.

 

This is really annoying. It'd definitely be nice to know if someone at HQ is actually looking into this. The +8 hour offset on field notes is very, very irritating!

Share this post


Link to post

I just began having this problem. I upload field notes via API from the Cacchesense app for android phone. My caches appear to move forward 8 hours. This started between 1/15 and 1/17/17. Phone, computer and GC profile all show correct time zones for my location.

Share this post


Link to post

Seriously, this problem is REALLY annoying!

Especially when visiting personal TBs on composing, if the incorrect date isn't caught, then all those TB log dates are stored with the same incorrect +8hour date used for the find log.

All my caching after 4pm last night were pushed to today's date in the Field Note list for composing.

 

The problem is not with the app's data or functionality. The dates are stored correctly in the app. Something is saving the date incorrectly on uploading to the website via the old/non-API method.

 

Some response here would be helpful - is this just going to be marked off as a defunct, obsolete mobile app function? If so, then perhaps it should be blocked outright, rather than continuing to allow incorrect data to be stored online. If it's going to be fixed, then at least maybe an acknowledgement that there is in fact a problem being examined would be comforting? signalsad.gif Any solution - whether it's something we need to do, or a bug fix on the web end - would be greatly appreciated!

Share this post


Link to post

The problem is not with the app's data or functionality. The dates are stored correctly in the app. Something is saving the date incorrectly on uploading to the website via the old/non-API method.

Yes, this is getting annoying.

 

You keep telling us that the app is using an old, non-API method of posting field notes, and that this seemingly-unsupported method no longer works correctly. Okay. So what? Why don't the app developers just use the supported API method? Frankly, it's very confusing to me that they would implement some API functions (at least the "Live" searching seems to use the API), but decide to go to the effort of using an alternate, non-API method for the field notes. Using the API for field notes would likely make things easier for the developers as far as coding and ongoing compatibility, and would provide the users with a supported function that's successfully being used by many other 3rd-party software packages.

Share this post


Link to post

You keep telling us that the app is using an old, non-API method of posting field notes, and that this seemingly-unsupported method no longer works correctly. Okay. So what? Why don't the app developers just use the supported API method? Frankly, it's very confusing to me that they would implement some API functions (at least the "Live" searching seems to use the API), but decide to go to the effort of using an alternate, non-API method for the field notes. Using the API for field notes would likely make things easier for the developers as far as coding and ongoing compatibility, and would provide the users with a supported function that's successfully being used by many other 3rd-party software packages.

I know that the next thing I say will be used as fodder to dismiss my concern, but that misses the point I'm making.

Geosphere hasn't yet had a significant app update since the API was initially implemented. As far as my knowledge, which may not be accurate as it relates to the app's coding, the field notes upload was a function implemented before the API was available has was not been updated since API-field-note-uploading was made available. We don't have confirmation yet if the developer will be making another significant update to the app.

 

However, this function was working perfectly fine up until late last year when some update was made to the website or API or something, which broke the 'old' functionality. My point is that it would be nice to hear from developers what the status of this bug is which is breaking old functionality. Is it being addressed? Will it not be addressed and left as broken because it's considered obsolete?

 

As of now there's been no response whatsoever about the issue, so those of us using any app or website that doesn't employ the "new" API field note uploads (which seems to be the only method that works properly, from what I've observed in various threads related to timezone issues) are doomed to perpetual incorrect dates on our uploaded field notes. But this field note date issue does appear to span more than merely Geosphere-field-note-uploads, as evidenced by a few other commenters.

 

As a web-app developer, this broken functionality concerns me. lostsignal.gif

 

If this particular function (old field note upload method) isn't relevant to your uses, then feel free to skip this thread :Plaughing.gif

Edited by thebruce0

Share this post


Link to post

As a web-app developer, this broken functionality concerns me. lostsignal.gif

 

I never used Geosphere though it seems to have a strong following that is moving to Cachly in droves and looking for the same features. What I get from reading the threads here and on the Cachly forum is that Geosphere used the API when available and maybe went outside the API when a feature was implemented in the app which wasn't currently supported by the API. If the developer kept the app updated, they could migrate to leveraging the API if a new API was introduced that was previously coded around -or- they could adjust their app when relying on non-API approaches when those changed on the site or whatever they called. The latter mimics what the development team of "the app which shall not be named" needs to constantly do. Here it seemed neither has occurred and I wouldn't expect GS to do anything about it.

 

I wish Groundspeak focused on making what they do support consistent which we know isn't the case depending where you log. Because they can't do that well, I wouldn't even ask they do something to accommodate an abandoned app.

Share this post


Link to post

As a web-app developer, this broken functionality concerns me. lostsignal.gif

 

I never used Geosphere though it seems to have a strong following that is moving to Cachly in droves and looking for the same features. What I get from reading the threads here and on the Cachly forum is that Geosphere used the API when available and maybe went outside the API when a feature was implemented in the app which wasn't currently supported by the API. If the developer kept the app updated, they could migrate to leveraging the API if a new API was introduced that was previously coded around -or- they could adjust their app when relying on non-API approaches when those changed on the site or whatever they called. The latter mimics what the development team of "the app which shall not be named" needs to constantly do. Here it seemed neither has occurred and I wouldn't expect GS to do anything about it.

 

I wish Groundspeak focused on making what they do support consistent which we know isn't the case depending where you log. Because they can't do that well, I wouldn't even ask they do something to accommodate an abandoned app.

 

Again, I'm not saying they must do something about it. I'm asking for some response about what is happening with it. If it's going to be ignored, tell us. Like you said, many 3rd party apps uploaded field notes before it was available in the API. And again, I don't know for sure what the precise problem is here. The assumption is that geosphere is using a non-API field note upload function. But there's been no response at all about what the problem may be. As a web app developer, I'd be looking into it to determine what could be causing the timezone bug, and then determine if it's worth fixing. And for the sake of my users, I'd inform them one way or another. I mean, if I implemented some new function that broken an existing one - old or not - I'd want to know if anything else may have also been broken with the same update.

Ignoring a known bug shouldn't be an option...

 

I'd just like to know the status of this problem of +8 hour timezone offsetsf or field note uploading. Whether it's obsolete and abandoned non-API field note uploading (which is definitely not equivalent to the processes used by the app-that-shall-not-be-named since Geosphere is an approved app that has never broken the TOU) meaning Geosphere and other resources using that method will be forced to change or be doomed to incorrect upload values, or whether a fix is in the works.

 

As a developer, specific to this bug, I'd be all over this - why is a simple timezone being shifted by 8 hours, all over the world? The only consistent aspect to the various reports (not just from geosphere) is that perhaps the note date/time is being (properly) converted to GMT for storage, but then assumed to be Pacific (GSHQ) at some point (timezone being dropped or strictly overridden to GMT-8), and once again converted to GMT which bumps every date/time by 8 hours, regardless of the user's native timezone. To me, that's a code bug somewhere that could be affecting other functions. Who knows.

 

Regardless, there's an inconsistency, and broken functionality. Is it being reviewed? If it's never going to be fixed, I'd like to know. Then at least we who are doomed to its problem can, for the time being, attempt to develop some workaround ourselves to attempt to remove the annoyance of manually editing every field note date posted after 4pm local time, until the time if/when any 3rd party app developer addresses the problem on their own end. tired.gif

Edited by thebruce0

Share this post


Link to post

I'd just like to know the status of this problem of +8 hour timezone offsetsf or field note uploading. Whether it's obsolete and abandoned non-API field note uploading (which is definitely not equivalent to the processes used by the app-that-shall-not-be-named since Geosphere is an approved app that has never broken the TOU) meaning Geosphere and other resources using that method will be forced to change or be doomed to incorrect upload values, or whether a fix is in the works.

 

As a developer, specific to this bug, I'd be all over this - why is a simple timezone being shifted by 8 hours, all over the world? The only consistent aspect to the various reports (not just from geosphere) is that perhaps the note date/time is being (properly) converted to GMT for storage, but then assumed to be Pacific (GSHQ) at some point (timezone being dropped or strictly overridden to GMT-8), and once again converted to GMT which bumps every date/time by 8 hours, regardless of the user's native timezone. To me, that's a code bug somewhere that could be affecting other functions. Who knows.

 

Regardless, there's an inconsistency, and broken functionality. Is it being reviewed? If it's never going to be fixed, I'd like to know. Then at least we who are doomed to its problem can, for the time being, attempt to develop some workaround ourselves to attempt to remove the annoyance of manually editing every field note date posted after 4pm local time, until the time if/when any 3rd party app developer addresses the problem on their own end. tired.gif

I feel I answered your questions in my last reply. They (Groundspeak) have no need to respond or comment on something that isn't supported, which is what it seems Geosphere might have been doing. Groundspeak could never know what trick/method the Geosphere developer used to facilitate an app function that wasn't officially supported. If it doesn't break their app or officially supported API, everything is "working". Imagine if you found a trick to do some Google Map hack that wasn't supported and then when Google updates your Map app your hack breaks. Do you expect Google to respond/address it?

 

The timezone issue with Groundspeak is a mess throughout their world and there's no question it is broken/inconsistent. But since they can't fix their own supported timezone issues after a decade it seems unreasonable/unlikely they will address one they don't officially support. Yes, it doesn't help you with the behavior you are seeing but stop hoping for a miracle so you aren't disappointed day after day.

 

The only guarantee you should bet on are that timezone handling and the stored date/time for cache logs and TB logs is inconsistent. That you can take to the bank.

Share this post


Link to post

Ok, I'll take it a step further - I'm confident in saying it's guaranteed that the method Geosphere uses to upload field notes was a supported method; the same method than any 3rd party app or website would have used to upload field notes. Definitely not a method that was a misuse of something or a 'trick' to get around lack of functionality. I'll stand by Geosphere and its developer in that regard.

 

"But since they can't fix their own supported timezone issues after a decade it seems unreasonable/unlikely they will address one they don't officially support."

Agreed, however this problem arose late last year with an update they rolled out, and this new iteration of the timezone problem hasn't been addressed at all, to the best of my knowledge. So there is no reason to believe that either explanation is true - that it's obsolete and unsupported, or that it's a known issue that's being addressed. Only silence. That is my concern, the basis of my request.

Please? Can has recognition some way?

Share this post


Link to post

I feel I answered your questions in my last reply. They (Groundspeak) have no need to respond or comment on something that isn't supported, which is what it seems Geosphere might have been doing. Groundspeak could never know what trick/method the Geosphere developer used to facilitate an app function that wasn't officially supported. If it doesn't break their app or officially supported API, everything is "working". Imagine if you found a trick to do some Google Map hack that wasn't supported and then when Google updates your Map app your hack breaks. Do you expect Google to respond/address it?

 

I am sorry to interrupt this speculative discussion. :P

 

Because this bug definitely have impact to my daily life and it seems that nobody knows who to blame on it, I made some research with my network protocol analyzer.

 

The assumption was that field notes with wrong time zone from unsupported old applications somehow bypass the so called API-interface. My application is called "Neongeo" and it has already been unsupported for years. I did one fieldnote using this application and tracked all communication during the event. What I found is worrying me. I saw only communication between api.Groundspeak.com and my phone.

 

Because there is no change that my applications has been changed, I am pretty sure that api.Groundspeak.com has been modified to shift my field notes for 8 hours.

Share this post


Link to post

The assumption was that field notes with wrong time zone from unsupported old applications somehow bypass the so called API-interface. My application is called "Neongeo" and it has already been unsupported for years. I did one fieldnote using this application and tracked all communication during the event. What I found is worrying me. I saw only communication between api.Groundspeak.com and my phone.

 

Because there is no change that my applications has been changed, I am pretty sure that api.Groundspeak.com has been modified to shift my field notes for 8 hours.

 

What exactly is passed in the API call? Is it date, time & timezone or just date/time assumed UTC?

 

Also, is the API version based in that you were leveraging say .../v3/... and they've eventually dropped support for /v3/ and instead of it failing passed it along to .../v4/... which behaves differently?

 

Yeah, more speculation :-)

Edited by Team DEMP

Share this post


Link to post

I'm asking for some response about what is happening with it.

As a forum regular, I think you're aware that communication from Groundspeak can generously be described as "minimal". I doubt you'll get a response.

 

It's also been demonstrated many times that the squeaky wheel doesn't get the grease, so repeatedly requesting a response won't change their communication policy.

Share this post


Link to post

For preferences, sure, but this is an obvious bug. :P I don't care if they want to ignore geosphere (and any other resource that may use an 'outdated' function) - but there is a bug here. There is a known, reported, inconsistent data display happening.

Maybe the repeated requests for a response are futile and falling on deaf ears, but at least we can choose to return to the thread to raise attention to it as long as it remains outstanding (at least until moderators decide that shutting down any conversation related to the issue is more prudent on their end - but that would open a can of worms, methinks :P)

 

On another note...

I just tried the Geocaching.com/Garmin field note export option to Dropbox, copied to my desktop and uploaded that file directly via the web - everything was fine.

...I just tried the same process using Safari on the same phone (no need to use desktop - files can be uploaded via selecting a Dropbox file which is quite handy), and that file uploaded just fine as well. It didn't in Geosphere's browser, which may be due to its older in-app Safari widget version.

 

So, it's clear that field note upload via web is fine.

 

Geosphere does provide this (slightly tedious) workaround. Explanation:

1. Instead of uploading directly via the app (which clearly doesn't use the form field upload itself but likely some api function as arisoft explained), export the uploadable field notes using the "Geocaching.com/Garmin" type

2. Save to Dropbox (make sure you have an account connected)

3. Load up the Field Notes page in iOS Safari (have it saved as a bookmark for ease)

4. Select the file to upload, but choose from Dropbox (may need to toggle it as an option) - files are stored in Apps/Geosphere

5. Make sure the "Ignore logs before" option is untoggled, and upload.

 

Date/Times are all correct.

 

I wish it were easy to intercept the exchange of data between an iOS app and a web service to find out what exactly is happening in-app.

Edited by thebruce0

Share this post


Link to post

What exactly is passed in the API call? Is it date, time & timezone or just date/time assumed UTC?

 

Communication is encrypted. I have no way to tell what is going on.

 

Also, is the API version based in that you were leveraging say .../v3/... and they've eventually dropped support for /v3/ and instead of it failing passed it along to .../v4/... which behaves differently?

 

Due to encryption I have no idea about the version, but the last update to the app I used was made at 2013. Description says: "Secure and official geocaching.com access. Powered by Geocaching Live."

 

If this is question about dropped support then the app should stop working. As far as I see the support has already dropped for all versions. But the idea of using API-versions is to maintain functionality of old applications while developing new ones. If there is no "support" there should be no modifications either.

Share this post


Link to post

What exactly is passed in the API call? Is it date, time & timezone or just date/time assumed UTC?

 

Communication is encrypted. I have no way to tell what is going on.

 

Ah, sorry. I misunderstood and thought you were the developer of the discontinued application and could report what you were passing.

Share this post


Link to post

Annying bug, but we can only hope it has to do with implementing it in the new app.

Oveall just another reason to use a GPSr and not app

Share this post


Link to post

With the announced upcoming change to the logging API around timezones, it'll be interesting to see what happens for everyone. I expect a bit more normal date/time handling for those using out of the box apps that didn't account for this long standing bug, though at cutover time if someone is actively logging it could impact the order of logs. I foresee a bit of a mess for apps which tried to compensate for this date/time bug. I guess we'll see around May 8th when the change is supposed to go in effect.

Time zone changes:

In order to address long-standing inconsistencies in time zone handling between our website, our apps, and partner applications, we will be implementing a new system for handling time on geocache logs.

Currently, geocache logs submitted through the API are converted from UTC to PST. With the upcoming changes, our API will stop the conversion from UTC to PST. The API will pass through the utcDateLogged without conversion and an underlying service will then convert those UTC timestamps to the time zone where the cache is located. Due to the above changes, utcDateLogged timestamps on geocache logs submitted through the API should generally be submitted in UTC without offsets. Additionally, the API will return geocache logs with timestamps converted to the timezone of the cache.

Although we understand that not all logs are submitted in the time zone of the cache, we believe that this change will result in many more logs with the date intended by the player.

Edited by Team DEMP

Share this post


Link to post

Sidenote, I'm still slightly baffled as to why there is a problem with timestamps in general. I can understand the concern of which timezone to use in the case of a user caching in their non-home timezone (finding a cache not in their home zone), but if timestamps are stored in the database with the timezome, then there's no need for manual conversions before storage; the timezone already identifies the time that can be utilized anywhere in the world (ie, a cache logged at 4pm PST is the same time as one logged at 7pm EST, no need to convert them).

 

The only time it would need to be explicitly converted is if the database doesn't store timezone, and needs to assume a universal timezone for its storage (ie, all incoming logs need to be converted to PST because in the database there's no timezone identifier - whereas if timezone is stored, then most likely the database handles the timestamp properly anyway).

Timezone conversion really only needs to happen when the timestamp is made use of and displayed.

 

If the 'change' is that all Find logs are going to be stored using the cache listing's local timezone, then a Find log timestamp would be converted to the local cache timezone to determine the Y/M/D component w/o time for log sorting (log dates are never affected by timezone once saved), and the timestamp can then be stored as is for reference and that secondary sorting of logs.

 

Now what am I missing? I'm sure there's something...huh.gifcute_animated.giflostsignal.gifph34r.giflaugh.gif

 

ETA: btw, field notes are still being saved +8 hours offset. My working theory:

1. App uploads field note as 9:24am ET

2. Site strips timezone and stores it as 9:24am (PT).

3. For Field Notes page, site converts time to UTC, which is +8 hours, and displays on the page as 17:24pm (no timezone identified).

 

Here's a question, what is the timezone assumed for the Field Notes page? Is the user's local timezone? Is it UTC? Pacific? Cache local? There's no indication... one would assume the user's local timezone. (which really doesn't make sense how 9:24am ET would be getting converted to 5:24pm ET).

Edited by thebruce0

Share this post


Link to post

With the announced upcoming change to the logging API around timezones, it'll be interesting to see what happens for everyone. I expect a bit more normal date/time handling for those using out of the box apps that didn't account for this long standing bug, though at cutover time if someone is actively logging it could impact the order of logs. I foresee a bit of a mess for apps which tried to compensate for this date/time bug. I guess we'll see around May 8th when the change is supposed to go in effect.

I am also interested to see what will happen after the fix date. Glad to see that the devs have been working on this issue.

 

ETA: btw, field notes are still being saved +8 hours offset. My working theory:

1. App uploads field note as 9:24am ET

2. Site strips timezone and stores it as 9:24am (PT).

3. For Field Notes page, site converts time to UTC, which is +8 hours, and displays on the page as 17:24pm (no timezone identified).

What do you mean by "being saved"? Are you referring to the timestamp shown on the field notes page? You may be seeing a +8 hour offset, but that's not universal.

 

I am in the PST timezone and this is what I see:

(1) Upload field notes from GPSr

--> Field Notes webpage shows the actual time that I 'found' cache on GPSr. If I saved a field note on my GPSr at 2:17pm, then the webpage shows 14:17:00.

 

(2) Save draft in official app (Android)

--> Field Notes webpage shows -7 hours from when I saved the draft in the app.

--> Drafts in app shows -14 hours from when I saved the draft in the app.

 

To expand on example #2 (official app), if I find Cache A at 1:55pm and Cache B at 2:05pm, both on March 10th:

--> Webpage shows Cache A - 3/10/2017 - 6:55am & Cache B - 3/10/2017 - 7:05am.

--> App shows Cache A - 3/9/2017 - ??? & Cache B - 3/10/2017 - ???. "???" because app does not show a timestamp.

Edited by noncentric

Share this post


Link to post

ETA: btw, field notes are still being saved +8 hours offset. My working theory:

1. App uploads field note as 9:24am ET

2. Site strips timezone and stores it as 9:24am (PT).

3. For Field Notes page, site converts time to UTC, which is +8 hours, and displays on the page as 17:24pm (no timezone identified).

What do you mean by "being saved"? Are you referring to the timestamp shown on the field notes page?

Yes

 

You may be seeing a +8 hour offset, but that's not universal.

 

I am in the PST timezone and this is what I see:

(1) Upload field notes from GPSr

--> Field Notes webpage shows the actual time that I 'found' cache on GPSr. If I saved a field note on my GPSr at 2:17pm, then the webpage shows 14:17:00.

 

(2) Save draft in official app (Android)

--> Field Notes webpage shows -7 hours from when I saved the draft in the app.

--> Drafts in app shows -14 hours from when I saved the draft in the app.

 

To expand on example #2 (official app), if I find Cache A at 1:55pm and Cache B at 2:05pm, both on March 10th:

--> Webpage shows Cache A - 3/10/2017 - 6:55am & Cache B - 3/10/2017 - 7:05am.

--> App shows Cache A - 3/9/2017 - ??? & Cache B - 3/10/2017 - ???. "???" because app does not show a timestamp.

Interesting.

I presume your device's timezone and profile timezone are in sync? And it's Pacific time?

 

Uploaded field notes per #1, presuming that's how you loaded them from the GPSr, as also tested manually with text files, don't seem to have a timezone issue.

 

So for #2 - your app seems to have timestamp issues as well. And this is the official Geocaching app? blink.gif

 

You create a 'draft' on 3/10 @ 1:55pm (let's ignore seconds) in your device timezone.

-> The Field Notes page shows the draft time as 3/10 @ 06:55:00, which is 7 hours behind (presuming times on the page are in the same user profile timezone).

-> The official GC app shows the draft time as 3/9 at some time, which means at least 14 hours behind.

Neither of these views are correct. And both of each views are purely with official functions...?

ohmy.gif Something's really not right here. And that's not even the 3rd party app API use which is my use context.

Share this post


Link to post

ETA: btw, field notes are still being saved +8 hours offset. My working theory:

1. App uploads field note as 9:24am ET

2. Site strips timezone and stores it as 9:24am (PT).

3. For Field Notes page, site converts time to UTC, which is +8 hours, and displays on the page as 17:24pm (no timezone identified).

What do you mean by "being saved"? Are you referring to the timestamp shown on the field notes page?

Yes

 

You may be seeing a +8 hour offset, but that's not universal.

 

I am in the PST timezone and this is what I see:

(1) Upload field notes from GPSr

--> Field Notes webpage shows the actual time that I 'found' cache on GPSr. If I saved a field note on my GPSr at 2:17pm, then the webpage shows 14:17:00.

 

(2) Save draft in official app (Android)

--> Field Notes webpage shows -7 hours from when I saved the draft in the app.

--> Drafts in app shows -14 hours from when I saved the draft in the app.

 

To expand on example #2 (official app), if I find Cache A at 1:55pm and Cache B at 2:05pm, both on March 10th:

--> Webpage shows Cache A - 3/10/2017 - 6:55am & Cache B - 3/10/2017 - 7:05am.

--> App shows Cache A - 3/9/2017 - ??? & Cache B - 3/10/2017 - ???. "???" because app does not show a timestamp.

Interesting.

I presume your device's timezone and profile timezone are in sync? And it's Pacific time?

 

Uploaded field notes per #1, presuming that's how you loaded them from the GPSr, as also tested manually with text files, don't seem to have a timezone issue.

 

So for #2 - your app seems to have timestamp issues as well. And this is the official Geocaching app? blink.gif

 

You create a 'draft' on 3/10 @ 1:55pm (let's ignore seconds) in your device timezone.

-> The Field Notes page shows the draft time as 3/10 @ 06:55:00, which is 7 hours behind (presuming times on the page are in the same user profile timezone).

-> The official GC app shows the draft time as 3/9 at some time, which means at least 14 hours behind.

Neither of these views are correct. And both of each views are purely with official functions...?

ohmy.gif Something's really not right here. And that's not even the 3rd party app API use which is my use context.

Yes - my computer, phone, everything is set to Pacific Time (PST).

 

Yes - the timezone is an issue. It's a known issue that Groundspeak has acknowledged and is working on, based on Team DEMP's post #86.

 

My point in posting was that the behavior you're seeing with Geosphere seems to be odd and might be more about Geosphere than with Geocaching.com. Your "working theory" seems flawed, although I'm not sure exactly how. My guess would be that Geosphere is not saving/sending your field notes in UTC time.

Share this post


Link to post

My point in posting was that the behavior you're seeing with Geosphere seems to be odd and might be more about Geosphere than with Geocaching.com. Your "working theory" seems flawed, although I'm not sure exactly how. My guess would be that Geosphere is not saving/sending your field notes in UTC time.

 

If you check back in the thread, we've run numerous tests, verified that the data is valid locally, and it doesn't seem to be just geosphere.

 

The "working theory" is based on non-API-upload and non-web-upload handling of Field Notes. I don't know exactly how Geosphere or other apps with the issue are sending field notes, but I believe those are the remaining options based on what we've seen working and not working.

Again, nothing changed in Geosphere at the point that uploaded field note timezones started having offsets, but there a number of gc.com web updates around that time.

 

But it's certainly affecting more than just this context as there are a number of reports in other areas where timezones don't seem to be saving properly. IIRC some other contexts have been fixed, but others are still outstanding (such as this non-api 3rd party field note upload function).

 

The workaround, at least for Geosphere, is to manually export field notes as the uploadable text file type ('Geocaching.com / Garmin'), and upload that file - in the app the easiest manner is to export this file to Dropbox, load the Field Notes page in Safari, and upload the file from the Dropbox location which conveniently Safari allows.

 

That upload works fine producing correct timestamps - because Geosphere's data is valid. So it really is the uploading from the 3rd party app via a non-web, non-api function, which is causing a timezone offset, and with nothing having changed in the app when timezones broke, it must be a server-end update that changed it.

Share this post


Link to post

My point in posting was that the behavior you're seeing with Geosphere seems to be odd and might be more about Geosphere than with Geocaching.com. Your "working theory" seems flawed, although I'm not sure exactly how. My guess would be that Geosphere is not saving/sending your field notes in UTC time.

 

If you check back in the thread, we've run numerous tests, verified that the data is valid locally, and it doesn't seem to be just geosphere.

 

The "working theory" is based on non-API-upload and non-web-upload handling of Field Notes. I don't know exactly how Geosphere or other apps with the issue are sending field notes, but I believe those are the remaining options based on what we've seen working and not working.

Again, nothing changed in Geosphere at the point that uploaded field note timezones started having offsets, but there a number of gc.com web updates around that time.

 

But it's certainly affecting more than just this context as there are a number of reports in other areas where timezones don't seem to be saving properly. IIRC some other contexts have been fixed, but others are still outstanding (such as this non-api 3rd party field note upload function).

 

The workaround, at least for Geosphere, is to manually export field notes as the uploadable text file type ('Geocaching.com / Garmin'), and upload that file - in the app the easiest manner is to export this file to Dropbox, load the Field Notes page in Safari, and upload the file from the Dropbox location which conveniently Safari allows.

 

That upload works fine producing correct timestamps - because Geosphere's data is valid. So it really is the uploading from the 3rd party app via a non-web, non-api function, which is causing a timezone offset, and with nothing having changed in the app when timezones broke, it must be a server-end update that changed it.

It may not be just Geosphere, but it has been noted in this thread that Cachly and Looking4Cache are fine.

 

I just tested GCDroid, and that was fine - the website shows a date/time that matches when I submitted the field note in the GCDroid app. I even tested the "bad app" for Android, which doesn't use the API, and that one worked fine. Finally, I tested GDAK, which was off by +1 hour (showed 21:40pm when it should be 20:40) consistent with not adjusting for DST. The official Geocaching app was -8 hours earlier this month, before DST shifted it to -7 hours.

 

Apps that are currently maintained (Cachly, Looking4Cache, GCDroid, Geocaching) are working okay, but an app that hasn't been updated since 2013 (Geosphere) doesn't work quite right. It seems the problem lies with the latter. If there was a change of some sort, then other apps have been able to adjust. It just seems odd to me that you continue to insist that there's an "issue" after a Lackey has stated in this thread that they can't help and the issue is likely with Geosphere.

Share this post


Link to post

It may not be just Geosphere, but it has been noted in this thread that Cachly and Looking4Cache are fine.

Yes, they use the API for field note uploads.

 

I just tested GCDroid, and that was fine - the website shows a date/time that matches when I submitted the field note in the GCDroid app.

Probably via API.

 

I even tested the "bad app" for Android, which doesn't use the API, and that one worked fine.

Likely by using the file upload in a non-condoned scraping manner. Irrelevant (also known to be working)

 

Finally, I tested GDAK, which was off by +1 hour (showed 21:40pm when it should be 20:40) consistent with not adjusting for DST. The official Geocaching app was -8 hours earlier this month, before DST shifted it to -7 hours.

So there is a timezone issue there. API? non-API? Web?

 

Apps that are currently maintained (Cachly, Looking4Cache, GCDroid, Geocaching) are working okay, but an app that hasn't been updated since 2013 (Geosphere) doesn't work quite right. It seems the problem lies with the latter. If there was a change of some sort, then other apps have been able to adjust. It just seems odd to me that you continue to insist that there's an "issue" after a Lackey has stated in this thread that they can't help and the issue is likely with Geosphere.

"It's not me."

"It's not me."

Lots of finger pointing.

 

The clincher, again, is that this issue appeared when there was no update to Geosphere or iOS, but after an update to the web. It can't be Geosphere in the sense of an update that broke it. Something broke Geosphere. My interest is in finding out what and why.

 

The steps would be to find out precisely (verifiably) how Geosphere submits field notes (and any other source that has timezone issues) - as approved partners, then this should be known or determinable - and track down the cause of the timezone issue(s). No one seems to be interested in this, and that is also what concerns me.

 

However, as there is a slightly tedious workaround (for Geosphere, but unknown for other problem 3rd party sources), it's not that important. I'm a web app developer. This programming bug guts me to the core :P (it's also bugs me that my hands are tied, without access to any source code)

Edited by thebruce0

Share this post


Link to post

I have been having this issue too and it has been causing me great frustration. My testing scenarios are not as extensive as theBruce0's but I can confirm it is not an issue isolated to Geosphere.

 

In the attached photo, I tried four different apps and all produced inconsistent results. It should be noted, I was in BC for the first one (UTC -8) and all the others were done in Alberta (UTC -7). The last column lists the app and date/time the log was created. The discrepancies range from six hours before to nine hours after.

 

Field%20Note%20Errors.png

 

Let me know if I can be of any further help in testing/troubleshooting.

Edited by mrcanoehead224

Share this post


Link to post

Hey now!

 

This is great news :D

 

Can everyone else who's had issues with timestamp field note uploaded re-test to verify things are working properly?

That is, the Field Notes page date (and time, currently not displayed) should be listed as UTC, while the Compose Log page should properly auto-populate with the local cache timezone.

Share this post


Link to post

Ok, I gave it a try and got the same results. Looks good as far as the actual log date when editing my field notes.

 

I had some existing field notes that I haven't had time to log yet. I also created a couple of notes each in Geosphere and Cachesense at varied times to simulate the same day locally but different for UTC. They both exhibit the correct day when logging before 5 PM local time (UTC-7) on the drafts page, those after 5 PM show April 13. Finally, I created a note in the official geocaching app and it showed up on the correct date regardless of time.

 

Now, once the time comes back to the drafts page, I'll be completely happy again. :)

Share this post


Link to post

The dates seems to be right now!

In my case I live in timezone UTC+1, so It's not so many times I find the caches between 12am and 1am, where the "margin of error" exists.

 

I don't like that the timestamps are gone!

 

I'll continue to log via GSAK and when I do some FTF-race online with c:geo.

 

Draft.png?dl=0

Edited by Tonky73

Share this post


Link to post

Nope, that's conjecture.

The app will only die when it's no longer supported in the OS, and though it is nearing that point, the developer has never once stated that there would be no more development, but has chimed in on the rare occasion to admit the delay and say that a new version is being developed. You can choose to believe it's a lie, you can choose to believe that he's incompetent and won't actually follow through, but the base facts are he's only said he's still here and GS is basically still alive.

 

The gaps between updates are disconcerting, and many are slowly moving to other apps, but from my experiences with other apps, GS is still the most data-oriented and flexible caching app, while others are more powerful and usable for the activity of geocaching. So I'll still be using GS as long as it works, along with other apps that provide newer feature sets, and hold out hope that we'll be surprised by a major version release (or alpha/beta invite) in the somewhat near future. :)

 

ETA: But none of that has anything to do with the Field Notes issue, which has shown to exist beyond the Geosphere app.

 

I, too, hope it won't go away but I'm told iPhones have changed how they handle data and, according to Apple, when iOS 11 comes out Geosphere won't work.

Share this post


Link to post

I, too, hope it won't go away but I'm told iPhones have changed how they handle data and, according to Apple, when iOS 11 comes out Geosphere won't work.

Yes, geosphere, amongst many other useful 32-bit apps, won't be compatible with the next major iOS update. It's an understandable progression, though very very unfortunate (that level of obsolescence happens all over the tech world in time). For my next phone upgrade I'm currently intending to keep my old phone on the 32-bit OS to make continued use of those 32-bit apps.

However if you love Geosphere I'd recommend chiming in over at the official forums to let Mark know so he can be perhaps nudged to be communicative again, since his last update said he was working on a new major version. Many many many months ago. With nothing since then. =/ (and this thread can remain focused on Field Notes)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 13

×