Jump to content

Nic Hubbard

Administrators
  • Posts

    3826
  • Joined

  • Last visited

  • Days Won

    386

Posts posted by Nic Hubbard

  1. 7 hours ago, jinta29 said:

    Is there any way to view multiple PQ's on the offline maps? My current PQ's for the state number 13 and I would like to view more than 1 PQ at a time. Thanks

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

  2. 1 hour ago, ciarmer said:

    Are there plans to include a way to upload in bulk? It doesn't take too long to upload five caches individually, but it might get a bit tedious if one has 20 or 30 finds waiting to be uploaded as field notes.

    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!

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

  4. 46 minutes ago, AnyMules said:

    My only hope is that an app like Cachly can be flexible enough to offer the option to correct the logs before they're sent (even if it's something that comes with a big warning message before enabling) for those of us not in the USA and wanting to use a different timezone.  Without that option, I, and many others that care about stats and having things logged and shown on their actual found dates across multiple web sites and applications will still have to use other workarounds (logging caches with GSAK, or on the Web Site, or with Geosphere) and won't be able to use Cachly (or some of the other apps) to their full extent.

    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.

  5. 45 minutes ago, Team DEMP said:

    What you noted and were told was my assumption too. There was a thread I'm sure I can find where someone claimed they were told by a GC developer that it required updating/data migration, etc which didn't make sense. 

    This possibly could be the case for very old logs. It might be that very old logs are not UTC.

    45 minutes ago, Team DEMP said:

    So if they properly store it as UTC, then they need to add in a view of the data using either browser/device timezone or a new account setting for timezone which just effects the display. The underlying data remains 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.

  6. 9 minutes ago, Team DEMP said:

    You findings match the analysis in the threads I've reviewed in the Geocaching forums.  I also had a pretty rough discussion in one of the threads where others, not in the know, claim it must be a HUGE issue because GC hasn't done anything to fix it. They claim it requires updating all data, etc. I completely disagree based on way too many years of implementing technology solutions and I expect there are multiple ways to address the situation. 

    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.

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

  8. 13 minutes ago, AnyMules said:

    I agree - from what I can see from all of that is that Geosphere MUST be doing some sort of correction as every other application is logging on the "wrong day".

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

  9. 2 minutes ago, Team DEMP said:

    You are able to capture the API request from Geosphere to GC?

    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.

  10. 6 minutes ago, AnyMules said:

    Hi Nic,  I'm in Australia/Adelaide (UTC+10:30), so half an hour different from Australia/Sydney (UTC+11:00).

    I hope that when you checked with the API that you didn't get my corrected version of the logs where I'd pasted the Cachly log text in to what was previously the Geosphere log so as not to upset the CO with a double log.

    I did post the data from the GPX file of the logs in my previous post before I did that.

    If you want me to log another one twice, let me know and I'll create a couple more perhaps on one of my own caches so as not to upset any other COs.

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

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

  12. 5 minutes ago, AnyMules said:

    As emailed - from the testing I did with the beta this morning, the date issue is still there.  I logged a cache (GC6AEGG) at 8:05am my time (UTC+10:30) this morning from both Cachly and Geosphere.  When looking on Geocaching.com, the Cachly log (the one with the complete text in the screenshot attached) has yesterday's date, while the Geosphere log (with just an "A" in the cache log) is dated with the correct date.

    Here is a bit more detail of what I get from the geocaching API:
     
    Log 1 (Cachly):
    Date(1481664900000-0800)
    Using the converter of that timestamp, it does show December 14, 8:35am. 
     
    Going to geocaching.com shows the wrong date:
     
    Log 2 (Geosphere):
    Date(1481704200000-0800)
     
    This also shows December 14, 8:35am.
     
    Attached screenshot from Cachly where it shows both of the logs on the 14th:
     
    IMG_5510.PNG
     
    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.
  13. 5 minutes ago, ciarmer said:

    Thanks so much, Nick for not only solving my offline logging issue but also for having the patience with me that actually led to a resolution of my GSAK integration problem!

    As another Geosphere refugee, I am loving this app more each day!

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

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

    Screen Shot 2016-12-13 at 9.50.42 AM.png

    Screen Shot 2016-12-13 at 9.51.15 AM.png

     

    Does this help clear things up?

  15. That amount of caches is currently too large for Cachly, as the memory it takes to load that will likely overwhelm your phone. The size limit really depends on your phones memory.

    We are working on our 2.1 update which will include changes to the database structure which will allow large lists like this with low memory and fast speeds. Stay tuned.

  16. 15 minutes ago, brudderman said:

    this does work well for "live" caches, but are the same options available for offline lists and maps? I'd like to hide my found caches when viewing a pocket query offline but am just now learning Cachly (v 2.0) and could easily be missing the feature to do this.

    Thanks!

    This isn't currently possible. This filtering feature will be added in our 2.1 version. 

×
×
  • Create New...