Jump to content

Date/Time Logging issue


AnyMules

Recommended Posts

Something that I've noticed in the last week of using Cachly is that the date and time that the caches were logged does not seem to be logged on Geocaching.com correctly.  Here is Australia, if I log a cache in the morning, it is dated the previous day on geocaching.com.  It seems that the app is ignoring the actual date and time the cache is logged and it is being logged at whatever time it is in Geocaching HQ.  I then have to go on to the geocaching.com web site and change the dates on the majority of caches I have logged as they are all incorrect.  Can this be fixed so that the caches are logged on geocaching.com with the actual date and time they are found?

Link to comment
Share on other sites

Same in New Zealand, it's always been like that.  The Groundspeak database stores log entries from Cachly in UTC (GMT).  I'm pretty sure Cachly is converting that back to local time when displaying the log (Nic?). The issue is that Geocaching.com just displays the raw entry, so for this far east it's usually the previous day.

Link to comment
Share on other sites

9 hours ago, Nic Hubbard said:

Do you have your geocaching.com time zone settings correct?

Yes, geocaching.com time zone is set correctly to UTC+9:30 Adelaide. 

The official app does the same thing, caches are often showing as being logged the previous day. 

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

There have been very long threads on the GC forums about this. Because I'm only 3 hours different from the timezone GC uses, and I don't normally cache at night let alone the wee hours of the next day, it doesn't impact me. Even so, I followed along on the discussions. 

What I can guess from all the info is that the API expects time passed to it in UTC/GMT but for some reason, the GC processing switches it to PT (Pacific Time) which means if you are logging on a different day, from the PT day, it shows as a different day it was logged. If you were in London which is currently 8 hours ahead of PT, you'd want to advance the time of the log by 8 hours so it showed as London's day vs GC's day or log after 8am London time and it would show the same day.

If I have the info accurate, I can understand Cachly's reluctance to purposely code against a really poor implementation that GC decided to go with and use that assumption to timestamp logs.

I have posted in the GC forum threads that it seems head scratching to me why GC refuses to just store logs as GMT, if they aren't already, and show date/time to be user specific based on time zone. I don't see any reason, and they have never responded in public, why they "fix" this behavior. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

56 minutes ago, Nic Hubbard said:

Would anyone want to test these changes in Cachly?

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I investigated this a few months ago:

By downloading a GPX file of my finds, I could see both Cachly and the official app end up with the correct timestamp in the logs, represented as 'Z'ulu (UTC) time.

Finds logged through the website are also stored as Zulu time, but the time portion is always noon PST/PDT, so 2016-02-07T20:00:00Z / 2016-06-22T19:00:00Z

So given Cachly's current setup is correctly recording the time, I'm reluctant to see it changed…

Link to comment
Share on other sites

The "official app" has always recorded the wrong date/time for me too.  Making most of my early finds "found" on the day before I actually found them.  That's one of the reasons I switched to Geosphere as my app of choice in my early caching days, but given the lack of support on that app, and the promises of updates since 2013, but nothing forthcoming, I switched to Cachly, but the logs seemed to have been marked the same as the official app, hence my request for a change.

Thanks Nic - I've now got the new version.  I'll give it a test soon, but will probably have to be tomorrow (my time). :)

Link to comment
Share on other sites

@AnyMules - I expect you might still see, depending on when you find/log, the web site show a find date of the day before you'd want it to. It's an error (though I'm sure they say it's a feature) on the GC end that Nic can't "fix". He could code for it, but he (and I, not that I have anything to do with Cachly) would consider coding on relying on a defect to not be acceptable. 

At best, if Nic wanted to try it, he might consider a user option to make the behavior work like Geosphere for those that want it but leave the annoying default behavior that GC implemented for others.  If enabled, the option would need to adjust the date/time of the log based on the difference between local time and GC time. Logging on the web site will also cause a bit of a difference vs the app. 

Link to comment
Share on other sites

Thanks @Team DEMP, I can understand that there are people who may want it to stay the same, and I would be happy for an option for people to switch the behaviour on and off if that's deemed a suitable alternative by @Nic Hubbard.

Logging caches on the web site also logs them with what I consider the "wrong" date as well - as, again, it logs the find with whatever the date and time are at GC HQ.  For those of us "down under", this is quite often the "previous day" until late afternoon when the US catches up to the right day.

So, unless something can be added to the app to make it use the local date/time when logging a cache, it will always be logging them at the GC HQ date/time which completely throws any stats generated out, and also can screw up cache streaks as, while I may have found a cache "yesterday" and "today" my time, the "HQ time" may show them both being on the same day due to the time difference - this means going back on-line on the web site and manually editing cache logs to get them to be logged on the correct day.  This was particularly painful the other day when I was using Cachly offline in a non-phone reception area all day and had to go back and edit 60+ cache logs individually to correct them all.

The Geosphere app appears to have some fix for this, and logs things at the local date/time it is told to.  GSAK also seems to use the dates it is set to use as well from what I have seen.  If I can just use one app to log everything correctly, then that'll make life much easier.  I'm keen to try the "fixed" version in the beta @Nic Hubbard sent me tomorrow to see how it fares.

Link to comment
Share on other sites

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.

Downloading that data in to GSAK and exporting it to GPX shows that the dates are very different:

    <groundspeak:log id="655540535">
      <groundspeak:date>2016-12-14T08:30:00Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">  A</groundspeak:text>
    </groundspeak:log>
    <groundspeak:log id="655539993">
      <groundspeak:date>2016-12-13T21:35:00Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Stopped by this one for a quick and easy find on the way to work. Thanks for the cache Team Cache Nerds. Found on 14 December 2016 at 8:05 am. Find# 3509</groundspeak:text>
    </groundspeak:log>

IMG_1911.PNG

 

PS: I've now gone back and corrected the logs/deleted the duplicate so the cache is no longer double logged and my find count is correct again.

Link to comment
Share on other sites

As noted above, there was no expectation the latest version addressed what you are seeing. It's an issue on Geocaching.com and not the app.  As noted above in multiple posts it doesn't make a lot of sense for Cachly to code a work around to a defect on Geocaching.com. I expect that is what your previous program did but it isn't right and could cause other issues. It would also cause a difference between logging in Cachly vs logging in the official app or via the website. At best, Cachly would need to make it an option to address the site defect. 

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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.

Edit: I've added some test logs to one of my own caches from multiple sources: https://coord.info/GC69QD2

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

21 minutes ago, Nic Hubbard said:

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. 

You are able to capture the API request from Geosphere to GC?  Or are you going under the assumption that they would be the same? I always figured that the way Geosphere or an app would want to compensate for the GC date/time issue was to use adjust the time sent knowing that whatever time is sent will be converted to PT (Pacific Time) for the date. So to log something right now that is UTC/GMT or UTC/GMT+ where they just switched days while PT is still on UTC DAY-1 you'd want to log as tomorrows date if the users timezone is the next day from Pacific Time.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Here's the data from the GPX file I just downloaded/exported with GSAK for the logs I created on GC69QD2 from various sources.  Where possible I chose a time of 10:00am, otherwise, the time was anywhere between 10:00am and 10:30am local Adelaide time.

    <groundspeak:log id="655550226">
      <groundspeak:date>2016-12-14T08:30:00Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Test log from Geosphere to assist Cachly software developer.</groundspeak:text>
    </groundspeak:log>
    <groundspeak:log id="655550087">
      <groundspeak:date>2016-12-14T20:00:00Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Test log from geocaching.com web site to assist Cachly software developer</groundspeak:text>
    </groundspeak:log>
    <groundspeak:log id="655550867">
      <groundspeak:date>2016-12-14T00:05:16Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Test log from new official iPhone app to assist Cachly developer.</groundspeak:text>
    </groundspeak:log>
    <groundspeak:log id="655550691">
      <groundspeak:date>2016-12-14T00:02:36Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Test log from old official iPhone app to assist Cachly developer</groundspeak:text>
    </groundspeak:log>
    <groundspeak:log id="655550622">
      <groundspeak:date>2016-12-13T23:30:02Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Test log from Looking4Cache Pro to assist Cachly developer.</groundspeak:text>
    </groundspeak:log>
    <groundspeak:log id="655550405">
      <groundspeak:date>2016-12-13T23:57:44Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Test log from Cachebot to assist Cachly Developer</groundspeak:text>
    </groundspeak:log>
    <groundspeak:log id="655550075">
      <groundspeak:date>2016-12-13T23:30:00Z</groundspeak:date>
      <groundspeak:type>Found it</groundspeak:type>
      <groundspeak:finder id="12456530">AnyMules</groundspeak:finder>
      <groundspeak:text encoded="False">Test log from Cachly app to assist software developer.</groundspeak:text>
    </groundspeak:log>
 

 

The geocaching.com web site only shows two of the above logs being on the correct day:

 

Logs.PNG

Link to comment
Share on other sites

What I see from the above is that PT being GMT-8 means even though the date/time logged is the "next day", it's only treats it as the next day if the log time is > 0800z. Thats why the 3rd one shows as the previous day even though the date/time is the next day. 

Whats odd to me is what is logged for Geosphere is what I thought it would do which is advance it by 8 hours to compensate, but if Nic is able to catch the API and see that it isn't doing them, I'm baffled. 

Link to comment
Share on other sites

Thanks again @Nic Hubbard.  Your assistance and quick response on these forums (and emails) is greatly appreciated.  

I've had a friend who uses c:Geo on Android to put a Write Note on that cache as well, and that's showing "Today" - so it appears that either a) It is Today now, or b): c:Geo is also doing whatever is required to log the correct date too.

Link to comment
Share on other sites

1 minute ago, AnyMules said:

Thanks again @Nic Hubbard.  Your assistance and quick response on these forums (and emails) is greatly appreciated.  

I've had a friend who uses c:Geo on Android to put a Write Note on that cache as well, and that's showing "Today" - so it appears that either a) It is Today now, or b): c:Geo is also doing whatever is required to log the correct date too.

c:Geo doesn't use the API and emulates what you'd do on the web site. Though it's an "app" it uses the geocaching.com functionality. I'd expect c:geo to match whatever occurs direct on the web site.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

2 minutes ago, Nic Hubbard said:

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?

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. 

Instead of addressing a real issue like this, they focus on changing the icons. Go figure. 

I would do the same as Nic or if it was a real issue for users, make it an option they could enable with a HUGE disclaimer on the potential problem that would occur if GC ever does it properly. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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. 

And should GC "fix" it, the info displayed for Geosphere generated logs and whoever else manipulated the log data will likely be out of whack. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

That all kind of explains why some of this is happening, but, as demonstrated, logging the cache on the Groundspeak web site (and from c:geo which we believe screenscrapes the web site) actually logged it with the correct day - so it's only looking "wrong" for anything that uses the API (apart from GSAK and Geosphere which seem to both apply a "fiddle factor" to get it right).

Unfortunately, with the way that the web site works, and its interaction with other sites (project-gc.com for example), having logs on groundspeak which don't respect the timezone they're logged in means that all the stats are very wrong for the large majority of geocachers (anyone not in the same timezone as GCHQ), hence why these "fiddle factors" are being applied by apps like Geosphere, and it seems, by their own web site too.

But, yes, I agree this this is more of a "Groundspeak issue" than a "Cachly issue", but isn't something that I'd think would be very easy for Groundspeak to address (given they haven't done so in the past 16 years - I'm pretty sure this isn't a new issue to them).  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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Thanks @Nic Hubbard.  I'll eagerly await this change, and use one of the workarounds in the mean time - probably "find cache using Cachly then log it with Geosphere", as that has worked for me the last few days, although it does mean that I need to keep two copies of the caches on my phone up to date - but that's not too difficult to achieve with a daily export of caches from GSAK via dropbox in to each app.

Again many thanks for your rapid responses and eagerness to make your app more functional and the best caching app out there.  I'm loving many of the features of Cachly.

Link to comment
Share on other sites

16 hours ago, Nic Hubbard said:

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.

Happy that it will be an option so I can stick with the current behaviour :)

Then I can carry on seeing the date lag a day, but know the data's correct.  And sticking with the default — and popular — behaviour means better chance of GS respecting the data if they ever fix the issue.

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

Hi @Nic Hubbard

I tested it this morning and it seemed to work fine. I created a cache note for a cache at 6:00am my time which would have previously shown incorrectly and it appeared on the correct date on geocaching.com. So far so good. I'll do some more logging with Cachly at various times over the weekend and see how it goes. Thanks for all the work you've put in to this. 

Link to comment
Share on other sites

Hey @Nic Hubbard,

I spent most of the afternoon today out caching and made about 25 logs with Cachly. All logs look good date wise, so I'm pretty happy with that. I only had to refer back to "the other app" on a couple of occasions where I had corrected coordinates stored, but hadn't migrated them to Cachly (or geocaching.com) yet.

So I'm pretty happy with the way this app is now working with regards to the dates. It all looks correct (although I'll probably need to test one day around the midnight cutover, but that won't be for a while yet). 

Thanks again for all your work on this issue!  

Link to comment
Share on other sites

  • 5 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...