Can time stamps be corrected?

[+rassilon256]

I went on a caching run with a friend on 2017-01-06 and got through 36 caches. I couldn't keep up with the logging as we made a lot of quick finds, the phone signal was patchy in places, and I was the driver. So I got 3 caches logged on the road, 3 at home that night, and I've now sat down and spent about 90 minutes logging the remaining 30 on the night of 2017-01-08.

 

Which is fine, except when I scrolled back through my logs after finishing I noticed that they aren't in the order they occurred (ie the same order I logged them in). The logs show up with 1-7 in order, but then jump to caches 15-17, then 19-37, 8-14, and 18 at the top. One of the main points for me was to log a journey that reflected what we actually did, and some of my logs would only make sense to myself or my friend (or anyone else who chose to read them later) if they were in the right order. I've got the right date stamp, I posted the logs in the right order, what else can I do?

[+on4bam]

I went on a caching run with a friend on 2017-01-06 and got through 36 caches. I couldn't keep up with the logging as we made a lot of quick finds, the phone signal was patchy in places, and I was the driver. So I got 3 caches logged on the road, 3 at home that night, and I've now sat down and spent about 90 minutes logging the remaining 30 on the night of 2017-01-08.

 

Which is fine, except when I scrolled back through my logs after finishing I noticed that they aren't in the order they occurred (ie the same order I logged them in). The logs show up with 1-7 in order, but then jump to caches 15-17, then 19-37, 8-14, and 18 at the top. One of the main points for me was to log a journey that reflected what we actually did, and some of my logs would only make sense to myself or my friend (or anyone else who chose to read them later) if they were in the right order. I've got the right date stamp, I posted the logs in the right order, what else can I do?

 

Congratulations, you discovered the weird timekeeping at GS

 

You should use the same logging method for all if you want to avoid things like this. I would delete all logs and redo them all via the same method. Saving a little time you could try leaving log 1-7 and just redo 8-36.

Edited January 8, 2017 by on4bam

[+lee737]

I no longer log on the road. I keep a book, and tick off caches as we find them, numbering as we go. When we get home, they are logged in the order they are found (or DNFd). I don't know if I'd be worried enough to delete and re-log 29 caches though, as long as the date was correct..... I do think, as on4bam has suggested, it is the only way to achieve what you want....

Edited January 8, 2017 by lee737

[+on4bam]

I log "found" (or DNF/NM) on my Oregon600. When back home I connect the GPS to my PC, import into GSAK, write logs and "publish all" including TBs via API. All logs are always in the correct order and it takes a lot less time to do than opening each cachepage, click "log this cache", write log and publish + do the same for each and every TB.

 

When on holiday, GDAK (android) will do the same (except for TBs).

 

Key point is to use the same method for all finds and not switch between website, apps...

[+rassilon256]

I use the phone app as my equivalent to your book lee737. I hit the log button, put in the number cache and if I have time put anything interesting I particularly want to remember, then save it for later.

 

So I understand that using different systems could cause a problem, presumably serverside my field logs are coded 2017-01-06-082358, and website logs 2017-01-06-X, or something. But I don't understand how that causes my problem. I logged my 17th, 18th and 19th caches on the website - same PC, same browser, same login session, and within about 5 minutes of each other. Same thing for my 7th and 8th, only they were about 30 minutes earlier. Except for the first 6 caches, it was all that one session. So I don't see why they are out of order while the first 6 (two different sessions in the app) are fine.

 

Have I missed the point of your explanation on4bam? Other than the don't switch methods one.

[+on4bam]

There's a thread about logging and servertime somewhere here. Someone ran tests using the gc app, API logging and website logging in order to find the source of the problem. You might try finding it using time and log as keywords. It's less than 3 months old.

[+thebruce0]

If you log with the website, where no time is requested, then AFIAK it's stored with the time at 00:00 GMT.

But more importantly, logs are always ordered by date first, then LogID - not time. (Unless timeless ones are displayed separately (last or first) for the day? Can't remember)

 

But the point mentioned above remains - if you want to ensure your ordering, use one method for all.

 

I only log by composing field notes as that's the simplest I know to maintain my log ordering. And if I have to insert a log mid-day between others I've already logged, I know I'll have to remove logs I want sequentially afterwards and re-post them for the same day. I'll post logs live from the road on occasion if I want to note an FTF for others who may be watching, or for other special reasons. But like above, I may resort to deleting and reposting if it ends up being in the wrong order.

 

Side note: Right now there is a small segment of people who are affected by a field note timestamp problem plaguing non-API field note submission (I believe) that's bumping the posted field note timestamp by 8 hours online.

[+on4bam]

I found the thread (it was started October 12th 2016).

[+thebruce0]

huh, very strange that this log ordering issue began occurring around the same time as the field notes started showing up offset by +8 hours on non-API-submitted notes...

 

It may well be that GS is now ordering logs in priority by 1] Date, 2] Time, 3] Log ID. Therefore logs with no time (web submitted) will be 'appended' (shown at the latest log) on its date (I'm thinking they're storing the datestamp and timestamp as separate database values, so no-time isn't considered midnight of the same date which would put them at the beginning, not end, of the day).

Ultimately though that is the most accurate ordering given logs that have no known time association (though no-time logs being first or last on a day could be arguable).

 

The interesting part is that TB logs are also getting re-ordered, which makes me think there's a time submission issue in that module. Either some include the time and others don't, or a timezone mixup is happening, or something...

 

With so many API functions and legacy non-API functions, I'm thinking there's a discrepancy in the submission processes somewhere that's causing a bunch of confusion and bad data (like +8 hours)

 

This was another thread that popped up about weird log dates.

Edited January 9, 2017 by thebruce0

[+Team DEMP]

Before changing icon colors/styles, I'm baffled why the focus isn't addressing fundamental platform/data consistency/stability issues that seem to have been lingering for years. No idea why the website and API are logging differently.

 

And lets not rehash the "it's hard" or "they said they need to update all the old data" excuses. Make it consistent regardless of method of logging before any other "enhancements" are considered.

 

[+rassilon256]

Thanks for the information thebruce0, and finding that thread on4bam. Good reading, and having some database admin and programming experience I find it all quite interesting. Unfortunately I still don't understand why a temporally contiguous group of logs submitted through a single interface have been rearranged. Everything I've read would suggest that I should have either 1-37 or 8-37, 1-7 rather than the jumble I seem to have. I guess I'll have to find time to copy/paste and recreate them if I really want them in the right order.

[+thebruce0]

Yep, that's your best bet for now.

We don't know the sorting method they are currently using. Anything we've said here is just gleaned from what we see on the cache page, and it's traditionally been Date->LogID (afaik); I haven't been watching for mixes of timestampped and no-timestamp logs on the same date.

Hopefully this will be addressed soon. Hopefully?

[+Chrysalides]

To answer the question in your title, there is no way to change the timestamp of logs except by relogging. To prevent this from happening in the future, I strongly advise against logging on the app.

 

(the long rambling details appear after this)

 

The last time I logged from the app was on October 13 2016 (Pacific time) because the website is down. I'm not 100% positive, but I believe I found this around 2 p.m. Since we were in DST during this time, I would expect the timestamp to show 2016-10-13T21:xx:xxZ. Instead, the GPX timestamp shows 2016-10-14T04:22:11Z, which would make the find at around 9 p.m. on Oct 13. I know I found this closer to lunchtime than dinner time, and it was still full daylight when I found it.

 

If you log from the website, it is also kind of screwed up, but at least the madness is predictable. If you're logging when DST is in effect in Seattle, time is always 19:00:00Z. When DST is not in effect, time is always 20:00:00Z.

 

I haven't verified this, but it would appear that on the web page, logs are sorted first by chronological order, then if the time is the same, it is sorted by log ID. I've seen log entries that were entered before I logged on the cache page, but when I log my find, my entry jumped in front of theirs (or, rather, since it is in reverse chronological, it appears below their log entry).

[+thebruce0]

Yep sorting is definitely Date, Time, LogID.

Though I'm pretty sure that new logs posted via web without time are shown at the end of the date in the log history. I've always relied on that... unless something's changed?

[+Chrysalides]

Though I'm pretty sure that new logs posted via web without time are shown at the end of the date in the log history.

Logs entered via web will always have time of 8 p.m. when daylight savings is not active, and 7 p.m. when daylight savings is active. They appear to take 12 noon Pacific time on that day, and convert it to UTC.

 

Example:

 

<Groundspeak:date>2013-12-28T20:00:00Z</Groundspeak:date>

 

I'm more puzzled by the very strange time that's recorded when logging through app. I'm not sure if someone's doing something strange such as getting current time in UTC, changing the time zone to Pacific (without adjusting time), then saving it, or something like that. There used to be a bug with field notes with a very similar issue.

Edited January 10, 2017 by Chrysalides

[+thebruce0]

There used to be a bug with field notes with a very similar issue.

You mean like this one?

[+Chrysalides]

There used to be a bug with field notes with a very similar issue.

You mean like this one?

Yes, but I was thinking of another one from at least 2 years ago.

 

To be fair, Groundspeak only claims to be the language of location, not time

Edited January 10, 2017 by Chrysalides

[+barefootguru]

I'm more puzzled by the very strange time that's recorded when logging through app. I'm not sure if someone's doing something strange such as getting current time in UTC, changing the time zone to Pacific (without adjusting time), then saving it, or something like that.

Last time I checked, the local time was being correctly converted to UTC and marked as 'Z'ulu time. Are you not seeing this?

[+Chrysalides]

I'm more puzzled by the very strange time that's recorded when logging through app. I'm not sure if someone's doing something strange such as getting current time in UTC, changing the time zone to Pacific (without adjusting time), then saving it, or something like that.

Last time I checked, the local time was being correctly converted to UTC and marked as 'Z'ulu time. Are you not seeing this?

The last time I logged with app was in October - that was the example I gave a few posts above. It might have been fixed since then. When was the last time you logged using the app?

 

Edit: still not fixed. See entry below.

Edited January 13, 2017 by Chrysalides

[+Chrysalides]

Last time I checked, the local time was being correctly converted to UTC and marked as 'Z'ulu time. Are you not seeing this?

Just for you, I did an experiment. I logged a note on my own cache using the Geocaching app and downloaded the GPX.

 

My time zone is set to Pacific time in my profile. I created the log at 14:50. UTC time is 22:50. In the log, time is 2017-01-14T06:50:10Z.

 

• 2017-01-13T14:50:10-08 : log entered, local time
  
• 2017-01-13T22:50:10Z : log entered, UTC
  
• 2017-01-14T06:50:10Z : log time in GPX
  

 

You can download the GPX and see for yourself here. Here's the log section:

 

<Groundspeak:log id="660243949">
 <Groundspeak:date>2017-01-14T06:50:10Z</Groundspeak:date>
 <Groundspeak:type>Write note</Groundspeak:type>
 <Groundspeak:finder id="1933996">Chrysalides</Groundspeak:finder>
 <Groundspeak:text encoded="False">Another experiment with date and time.</Groundspeak:text>
</Groundspeak:log>

 

Just for fun and giggles, I created another log with my time zone set to Samoa (UTC+13) and the time offset remains unchanged.

 

Speculating, it appears that the app is sending UTC time with time zone to Groundspeak's server. The server then treated UTC as local time and adjusted it to UTC, resulting in me caching 8 hours in the future.

[+hzoi]

Speculating, it appears that the app is sending UTC time with time zone to Groundspeak's server. The server then treated UTC as local time and adjusted it to UTC, resulting in me caching 8 hours in the future.

Yep. That's odd. But it explains why my logs can get jumbled if I do some on the app and some on the computer. And why it's possible for my logs to appear before my buddy's if I log from the website (even using my phone) and my buddy uses the app.

[+thebruce0]

That 8 hour phenomenon is being discussed in the Field Notes thread linked here as well.

There is a time handling issue on Groundspeak's end, as for Field Notes specifically, the problem began late last year, and not due to any update from the user/app(s) end.

 

Something on the server end changed causing an 8 hour offset (regardless of user timezone) affected some direct-to-log posting from old methods, and non-API field-note uploading. And it hasn't yet been fixed.

[+Chrysalides]

Something on the server end changed causing an 8 hour offset (regardless of user timezone) affected some direct-to-log posting from old methods, and non-API field-note uploading. And it hasn't yet been fixed.

Can you try the same thing I did and see if you're also seeing an 8 hour offset, since your time zone is UTC-5?

 

If the offset is also 8 hours, then the next question is whether it changes to 7 hours during DST (which we can't test until March 12).

 

If it does, then it is because someone is treating UTC as Pacific Time.

[+thebruce0]

Note posted just now from the 'new' app @ 1:43pm ET -> GPX = T18:43:44Z (6:43pm GMT) [+5h, Correct]

Field note via Geosphere uploaded @ 1:46pm ET -> Web = 21:46:49 (9:46pm GMT) [+8h, Incorrect]

Test log posted direct via Geosphere @ 1:47pm ET -> GPX = T18:47:20Z (6:47pm GMT) [+5h, Correct]

Test log posted direct via classic app @ 1:52pm ET -> GPX = T18:52:07Z (6:52pm GMT) [+5h, Correct]

 

Same results as posted in the Field Notes thread.

[+Chrysalides]

Note posted just now from the 'new' app @ 1:43pm ET -> GPX = T18:43:44Z (6:43pm GMT) [+5h, Correct]

Field note via Geosphere uploaded @ 1:46pm ET -> Web = 21:46:49 (9:46pm GMT) [+8h, Incorrect]

Test log posted direct via Geosphere @ 1:47pm ET -> GPX = T18:47:20Z (6:47pm GMT) [+5h, Correct]

Test log posted direct via classic app @ 1:52pm ET -> GPX = T18:52:07Z (6:52pm GMT) [+5h, Correct]

 

Same results as posted in the Field Notes thread.

I just tried with the new app (latest version) on Android. I'm still seeing +16 h.

 

<Groundspeak:log id="660602370">
 <Groundspeak:date>2017-01-16T06:36:17Z</Groundspeak:date>
 <Groundspeak:type>Write note</Groundspeak:type>
 <Groundspeak:finder id="1933996">Chrysalides</Groundspeak:finder>
 <Groundspeak:text encoded="False">Note created at 2:36 p.m. Pacific Time for testing.</Groundspeak:text>
</Groundspeak:log>

 

I wonder if I log a cache late at night on phone, will it be logged as found on the next day?