Log dates in my finds PQ

[+abcdmCachers]

I'm hoping someone can definitively explain log dates in the my finds PQ. I notice in an older PQ I have, log dates look something like this:

<Groundspeak:date>2008-08-21T19:00:00</Groundspeak:date>

 

Now, there is a Z appended after the time. I have to plead ignorance here, but doing a little resarch, it appears to be UTC time (formerly GMT), correct?

 

I'm author of CacheStats and I have a user where half his dates are reported correcty and the other half are off by one day. Seems older caches the time is 07:00:00Z and newer caches are T19:00:00Z and some are T20:00:00Z. I'm guessing CacheStats is incorrectly translating the 20:00 to the next day.

 

So my questions:

- Should I be translating the time from UTC into some other time zone? If so, which one? Or should I not translate at all and just take the date of the find as whatever is in the date portion, regardless of what the time of day is?

- Any significance to the different times logged (7:00 vs. 19:00 vs 20:00)? I'm thinking 19/20 is probaby due to DST. What will be the standard going forward?

- Somewhat related, I've also noticed and reported (http://forums.Groundspeak.com/GC/index.php?showtopic=237318&hl) that some times in the GPX file are random (i.e. not 7, or 19) and the day off by one. Anyone know if that has been resolved?

- Was this change communicated to GPX developers? If not, again I ask that a reliable communication platform be set up for this type of thing. In the past I suggested taking down the pinned "GPX application developers" thread which is worthless and misleading, and replace it with a admin-only thread that diseminates this info.

 

Thanks for any info you can provide.

[+Chrysalides]

OK, I'm not 100% certain, but this is what I know:

 

1. Groundspeak converts all time to Pacific Time (Seattle local time) before displaying. So 07:00Z during daylight saving time, and 19:00Z/20:00Z will be shown on the same day.

 

2. AFAIK Groundspeak does not use the user's or the cache's local time zone for the conversion, but always use Seattle time.

 

3. Some log entries entered from iPhone seems to have an actual time stamp, and that may occasionally mess up the display.

 

Hope this helps.

[+Bear and Ragged]

Suggest you check... There is a thread about this already, where the time zones are explained.

Will see if I can find it and post a link.

[+Bear and Ragged]

Thread link

 

Moun10bike's explanation post 5

[+tozainamboku]

Suggest you check... There is a thread about this already, where the time zones are explained.

Will see if I can find it and post a link.

That thread is about the time in the field notes (geocaching_visits.txt) file uploaded from Garmin units and this thread is about the My Finds pocket query. My guess is that when the changes were made to adjust the times in the geocaching_visits.txt file from UTC to Seattle time, that it changed the way time was treated in the My Finds PQ. It may be as simple as CacheStats seeing some caches that were manually logged on geoaching.com and others that were created from field notes so they have different time stamps (and dates). But it could also be that the time zone adjustments are being made where they shouldn't be. (Poor design and testing of a change - someone thought this was an easy fix when in fact a small change will often have unexpected ramification in a complex system like Geocaching.com.)

[robertlipe]

As a preachy developer of the GPX spec, the clear intent was for times in GPX to always be in UTC. http://www.topografix.com/gpx_manual.asp#time The ambiguity of local time in a storage format is just too gross. But this tag is a Groundspeak one and not a GPX one, so we can't declare it 'wrong' as it's still an 8601 time, it's just unfortunate.

 

This issue looks unrelated to the one in the Bear & Ragged's linked thread.

 

Newer PQs declare the time zone as "Z" (Zulu/GMT/UTC, give a little bit of rounding) which more authoritatively describes the time. Programs (including GPSBabel) reading an 8601 date without an explicit time zone will probably declare that a local time (which is almost never right for files shipped around the internet) and thus, it will be different for the "same" string declared in GMT.

 

We've seen no evidence in PQs that HMS is actually stored in the placement date and logs. If you're seeing some dates returned in implicit P[sD]T and some in explicit Z in the same PQ, that would be baffling - and certainly a problem for software that uses those dates.

[+Chrysalides]

My own My Finds (or should that be Your Finds now? ) only go back a bit more than one year, so this is my observation:

 

0. All Groundspeak:date entries are in Zulu time. There is no local time anywhere in the GPX.

 

1. All my found logs are either logged as 19:00Z or 20:00Z. I did not check, but I strongly suspect 19:00Z is inserted by the system when DST is in effect in Seattle. When converted to Pacific time, this becomes 12:00 noon. NM and NA are logged as actual time.

 

2. Proof that for display on the geocache page, log date is converted to Seattle Time : Published logs, and possibly other log types have time stamps that are not hard coded to 19:00Z / 20:00Z. When these logs are displayed, the time is converted to Seattle time in the cache display page. Take a look at GC230KF. In the GPX, publish log is dated 2010-01-16T03:53:50Z. On the cache page, it shows up as Jan 15, 2010. The cache is actually published at Jan 16, 12:53 p.m. local time (since it is in Japan, UTC+9) but that's a different topic entirely. And yes, I sacrificed one of my precious PQs to get this data

Edited January 22, 2010 by Chrysalides

[+abcdmCachers]

Thanks for your feedback. I finally had time to look into this in more detail. CacheStats was indeed reading the new date format in UTC and translating it to the local timezone. So the logs timestamped at 19:00 for the CacheStats user in Auckland (UTC+12) were translated to 07:00 the next day. Easy enough to fix.

 

This leads to my next questions. Almost all of the log dates are 7:00 or 19:00 depending on how old they are (or 8:00/20:00 depending on whether the date falls during DST or not). But I've seen a couple of instances where this is not true. Here is one example. Notice the time stamp in the GPX file is 01:44:06.

1. Are there other logging methods (e.g. via WAP or iPhone) that record the actual time? Or was this a temporary glitch in the logging system?
   
2. If there are other logging methods that use the actual time, what does the time in the GPX file represent? The time of day in Seattle that the log was created or the time of day in the user's local timezone? (Expressed in UTC of course).
   

Thanks again.

[+Chrysalides]

This leads to my next questions. Almost all of the log dates are 7:00 or 19:00 depending on how old they are (or 8:00/20:00 depending on whether the date falls during DST or not). But I've seen a couple of instances where this is not true. Here is one example. Notice the time stamp in the GPX file is 01:44:06.

1. Are there other logging methods (e.g. via WAP or iPhone) that record the actual time? Or was this a temporary glitch in the logging system?
   
2. If there are other logging methods that use the actual time, what does the time in the GPX file represent? The time of day in Seattle that the log was created or the time of day in the user's local timezone? (Expressed in UTC of course).
   

It seemed to be happening for a while with iPhone logs. As I do not have an iPhone, and it didn't affect any of my logs, I did not look further into it.