Jump to content

Nic Hubbard

Administrators
  • Posts

    3834
  • Joined

  • Last visited

  • Days Won

    387

Posts posted by Nic Hubbard

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

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

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

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

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

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

  8. Just now, AnyMules said:

    Yes please.  As I'm currently in a +10:30 timezone (usually +9:30, but we're in Daylight Savings Time now), the date/time of caches I log with Cachly are way out.  The last two days I've been using Cachly to find the caches, but Geosphere to log them (to get the correct logged date/time).  Obviously, using the one app to do it all would be preferable.

    If you aren't already a beta tester then send me an email using the Contact Support option within Cachly and I will get you setup.

  9. I have done some additional testing on this. I have set my iPhone to be on Sydney timezone. I created a log and viewed that created log (and submitted to geocaching.com) and the  date was correct everywhere, so I think within Cachly everything has been fixed. Have done this quite a few times in different ways and it all seems to be fixed.

    However, viewing that same log on geocaching.com has an incorrect date, for the reasons stated in the previous post...

  10. I have been doing some more testing with this and I think I have found a way for Cachly to show everything correctly. However, geocaching.com will continue to show things incorrectly because it seems they do the conversion. The correct data is stored, but they are seeming to convert it.

    Would anyone want to test these changes in Cachly?

    UPDATE: I was just told by one of the developers at Groundspeak that they are looking into the date issue on geocaching.com.

  11. 5 minutes ago, hidegoseek said:

    I have the California map downloaded, but it's considerably slower than the online maps so I only plan to use it when I don't have a data connection.  It might be due to the size of California and/or my old phone (5s 16GB).  

    The rendering speed on a 5s is currently pretty slow for high zoom levels. We are working to fix the performance of offline maps for older and newer devices.

  12. 17 hours ago, Bolling said:

    What's also really amazing is the level of customer support Nic gives to Cachly.  It's just great to see how he responds so quickly and then sometimes goes a step beyond.  One example is when a new user was confused about setting up an account.  Nic responded quickly with info about signing up at geocaching.com, but then he went a step further and made a pinned topic about it.  

    (I did do a cache run this weekend and didn't open my old standby app, Geosphere.  Cachly performed the job flawlessly).

    We really want to put users first. With that as our #1 goal we can make the best Geocaching app possible and provide the best support. :)

  13. 18 hours ago, AnyMules said:

    The GeoSphere app (which I'm trying to stop using) logs things with the right date and time stamp, so it must be possible.  Perhaps it's some sort of double adjustment by the Cachly app and the API. 

    From what I understand about Geosphere is that it back dates the time that you logged it, based on your time zone. I have not yet concluded that this is the best way to do it, because if in fact geocaching.com does fix it on their end, all of those dates would end up being incorrect. I will look into this further today.

  14. 20 hours ago, ciarmer said:

    Thanks Nic. This "Live" distance sorting bug seems to be focused only on corrected coordinates. There is an offline list distance sorting issue that is far more consequential. The sorting by distance for offline caches seems random and the list changes with every refresh. I believe you already know about that one but just in case, I thought I'd mention it.

    Yes, the sorting by distance issue has been fixed in 2.0.1, but thank you for pointing it out. :)

  15. 22 hours ago, ciarmer said:

    Can you also confirm that if it were working properly, the only thing that would happen is that the notes field in GSAK would be populated? That is one issue for me. The additional issue, or question for me is how would I import my found logs into GSAK in a way to change the "Found" status in GSAK. I guess I'm also looking for a way to convert those logs to a GPX file so that they could me imported into GSAK. Thanks so much for the quick replies.

    This feature can be used to upload the .txt file to the Field Notes page on geocaching.com: https://www.geocaching.com/my/uploadfieldnotes.aspx

    As for GSAK, I don't use it all that often. The feature was developed in conjunction with a GSAK beta tester of mine and did all the testing of this feature. You should be able to import that file and then publish those as finds using GSAK.

    There isn't currently a way to convert these to a GPX file. :(

  16. On December 9, 2016 at 8:18 PM, Kelsoboom said:

    At the risk of maybe causing confusion, I'd like to use this thread to bring up another unrelated (I think) issue that I've noticed.  It is similar to something I'd noticed previously with 1.1.7, but hadn't got around to reporting before 2.0 was announced, but now that 2.0 is out and the bug is there, I guess I'd better mention it.  I was out caching today, looking for a cache I had previously DNFed.  Because of my previous DNF log, the map symbol was a blue frownie.  After successfully finding the cache, I logged my find and went back to the map expecting to see the symbol changed to a smiley.  But not only was it still a frownie, but nearly ALL of the smileys on the map were now displayed as frownies.  I tried refreshing the map, but it didn't change, and even if I panned the map to a completely different location and refreshed, most of the symbols that should be smileys were blue frownies.  The only way to restore the display to normal seemed to be to force quit the app and restart; after that everything was back to normal.

    This is a bug that a few others have reported as well, but it is really hard to replicate, so I haven't been able to track it down.

    Are you able to replicate it?

×
×
  • Create New...