Early logged caches

[+smithysteve]

Why does logging caches before a certain time go down as a find for the day before, and what time is this? Ive noticed this on two separate occasions, is it because of the time difference here in the UK as opposed to USA??

[+The Jester]

The problem is that GC.com uses a default time on each log, based on Pacific Time zone (west coast of USA where they are located). This causes some weirdness at times - like a FTF log, mentioning the publish log, that is a day earlier than the publish log. I've wondered at times if one server is actually 12 hours off (showing PM during AM).

[+T.D.M.22]

This happens in Canada as well. Kinda. I think I am only 1 timezone different than GCHQ, so the time thing isn't really noticed. But I have noticed on caches that have been held-for example approved but not published until, say an hour before an event, that the first log will appear before the published log.

[+BlackRose67]

When I log my finds, I have GSAK and CacheSense (Android) configured to indicate the timestamp in my current time zone when I found the cache.

[+Bunya]

As I live in Australia, for most of the day the automatic date comes up as my yesterday.

With the increasing use of smartphone apps for geocaching, it has also become very common for our local cachers to log finds "on the go" which have the previous day's date on them here.

I think a lot of them don't know (or don't care) that the dates are one day behind the date they actually found the cache.

 

And an annoying "feature" is that for some logs - archive in particular - even if I put the correct local date, the GC date overrides it.

This means that if I want to archive a cache, I have to wait until (our) evening to get the right date on the log.

 

BTW as I write this it is just after 9am on 1/1/2014 here - so Happy New Year from Oz!

[Moun10Bike]

This has been a longtime issue. Here is my explanation from another thread:

 

This comes up a lot and is due to inconsistencies in the database that have built up over time (no pun intended). The gist of the issue that when logging a cache via the web site, the time stamp is (and always has been) set to noon Seattle time on the selected day. Conversely, logs posted via the API use UTC. The break occurs when the site then reads these differing time stamps. We have a lot of work to do to overcome this issue. Fixing it is a high priority but very complicated for a variety of reasons.

[+Isonzo Karst]

This has been a longtime issue. Here is my explanation from another thread:

 

This comes up a lot and is due to inconsistencies in the database that have built up over time (no pun intended). The gist of the issue that....

 

Short form, some server hamsters will drink coffee, and some won't ->>>> serve sync gets fried.

This trait is heterozygous, hard to fix in the gene pool.