Version 3.0.5: Fix for Incorrect Found Date

January 27, 2010

calendar Geocaching.com recently made a subtle change to the way dates and times are stored in GPX files. They are now stored using UTC format, or Coordinated Universal Time (the same time zone as Greenwich Mean Time). Because of this change, some of your found dates reported in CacheStats may be off by one day. This update provides a fix for that. But not all users are affected – it actually depends on your time zone. Read on if you want to know the gory details.

Dates and times in the old GPX file format didn’t specify any time zone, so CacheStats simply reported whatever date was saved in the GPX file as the date you found the geocache. But when the log dates changed to the UTC time zone (London for example), CacheStats automatically translated the date and time of the log to your local time zone. OK, so what? Turns out almost all of the log dates stored in a GPX file are either 07:00 or 19:00, not the actual time of day they were logged. So let’s say you live in eastern Australia, which is UTC plus 10 hours. Logs that have a timestamp of 07:00 were translated to 17:00 (07:00 in London = 17:00 in Australia). These logs posed no problem for CacheStats since the date was the same either way. But the logs that have a timestamp of 19:00 were translated to 05:00 the next day. Bottom line, the farther away from London you live, the more likely you are to encounter a problem. If you’re within 7:00 hours west of UTC (most of the United States) or within 5 hours east of UTC, you shouldn’t have any problems and there is no reason for you to download this update (this fix is the only change in the update). As my chemistry teacher used to say, “clear as mud, right?”. If you need the update, you can download it at the CacheStats web page. Simply download and reinstall – the previous version will automatically be uninstalled.