Nic Hubbard

Is this only happening for field notes? Or also for published logs from Cachly?

I have been talking with Clyde from GSAK about this issue and seeing how they fixed it. He has some great insight has he has been dealing with this since 2011 or maybe earlier. He provided some links with much more background on this issue: http://gsak.net/board/index.php?showtopic=17802&view=findpost&p=126030 http://gsak.net/board/index.php?showtopic=16698&view=findpost&p=116316 http://gsak.net/board/index.php?showtopic=16063&st=0&#entry111704 http://gsak.net/board/index.php?showtopic=19146&st=0&#entry137891

Are you force quitting Cachly, or is iOS doing it when it needs memory? Saving application state is something that is on our list. Working on feature priorities right now for 2.1 so will see where that comes in.

Having it open in Safari is a quick fix and I think that there are good arguments for this, so I will get it fixed right now. Won't be in 2.0.1 as we have already submitted that, but will be in 2.0.2.

There isn't currently a way to view more than one PQ at a time, but you can merge lists so that you can create a "master" PQ list. Just make sure you are using version 2.0.

Yes, this is a feature that we have been planning for a long time, but it just didn't make it into 2.0. It is now planned for 2.1 which is now being worked on. Stay tuned!

As you mentioned, it is a hard thing to keep track of. Are you using version 2.0? In 2.0 there was a number of fixes to make this keyword more reliable, but as you have stated there are still issues. I will look into it right away and get it fixed.

Happy to help!

Yes, I think adding an option with a big warning about this is what we will do. Still working on the specifics, so it might not be for a little while until we release that version. Thanks for everyone's input.

This option will actually need to come after 2.0.1. Working now to schedule it.

You are using the beta.

Yes, this feature is being added in 2.0.1. It is currently just a "quick search" and not the full filtering functionality that we will be adding in 2.1.

This possibly could be the case for very old logs. It might be that very old logs are not UTC. There is a Time Zone settings already on geocaching.com, but I really don't know what it affects. Would be curious to know.

I do not think that it would require updating all data. From what I have seen personally in the API and been told by the Groundspeak developers, the log dates are clearly stored as UTC dates. The real "bug" on geocaching.com is that it isn't taking the users set time zone into account and doing a conversion from the UTC date into the users localized date/time. Jason, one of the Groundspeak developers told me he put it on their list and they will be looking into the issue.

After doing more testing, and thinking about this more, I have come to the conclusion on a few things: Geosphere is doing UTC timezone manipulation to appease geocaching.com. Cachly is sending the correct UTC time for the log date. UTC time is the same in every timezone on earth since it is a calculation of seconds since 1970. geocaching.com should be taking the UTC time and converting that to the localized time zone set by the user in their geocaching.com settings. This is currently not happening. If and when geocaching.com fixes their UTC date issue, all manipulated Geosphere logs will be incorrect. If Cachly manipulated UTC dates based on the timezone, when geocaching.com fixes their UTC issue, these dates would also be incorrect. With those points in mind, I will be keeping our logging date the same. I don't want to manipulate the date so that geocaching.com "looks" correct, but the UTC date in the database is incorrect. Thoughts?

There hasn't been a date set. We are just finishing up 2.0.1 and will be starting work on 2.1 very soon.

Thanks guys. Will report back in a few hours when I get a chance to test everything again and some new time zone offset code.

Will do. Will be later tonight my time.

I will do some additional debugging tonight and post my findings here.

Yes, I can capture the API requests. That is what is puzzling. I submitted a log at basically the exact same time in Geosphere and Cachly, and captured both requests. Comparing them, they are almost identical, but the log on geocaching.com is different.

Thanks, I will use that time zone for testing. I did check when there were the two logs, and I looked using the API and the dates were very similar, see post above. This is why it is a bit confusing. I am not get convinced that the GPX from GSAK isn't doing some sort of conversion on the UTC date. Still investigating...

The part that is so far a mystery to me is that I can submit a log (on Sydney time) in both Cachly and Geosphere, and both show an almost identical UTC date being sent using the API. However, when viewing those logs on geocaching.com the dates are not the same. Cachly's is wrong.

Here is a bit more detail of what I get from the geocaching API: Log 1 (Cachly): Date(1481664900000-0800) http://www.epochconverter.com/timezones?q=1481664900000&tz=Australia%2FSydney Using the converter of that timestamp, it does show December 14, 8:35am. Going to geocaching.com shows the wrong date: https://www.geocaching.com/seek/log.aspx?LUID=f2b8cbbf-c491-46ff-a04b-acddcdbaeebf Log 2 (Geosphere): Date(1481704200000-0800) http://www.epochconverter.com/timezones?q=1481664900&tz=Australia%2FSydney This also shows December 14, 8:35am. Attached screenshot from Cachly where it shows both of the logs on the 14th: Another test I did was to submit a log (on Sydney time/date) in both Cachly and Geosphere. Both of them submitted the same UTC date, which when converted is correct: http://www.epochconverter.com/timezones?q=1481671920000&tz=Australia%2FSydney I think my conclusion of this whole situation is that geocaching.com is displaying the dates incorrectly. It seems that the API is displaying and sending the log dates correctly, and Cachly should be showing the correct log dates as well. geocaching.com does save the dates in the correct non-converted format, but the way they display them is incorrect. As I mentioned before, one of the developers at Groundspeak is aware of this issue, and I hope they can get it fixed ASAP.

As always, I am happy to help. Welcome to Cachly.

I think there is a bit of confusion here. Cachly is exporting a GSAK Note TXT file (same type and format that Geosphere exports). It creates a Field Notes .txt file that is very similar to the .txt format that GPSr units save. This file is to be used in the Geocaching.com access -> Publish Logs menu. Does this help clear things up?