Invalid dates crash GeoToad (Windows only?)

[GoogleCodeExporter]

What steps will reproduce the problem?
[Please include the relevant parts of your command line, if applicable.
Don't send your password though!]
1. Try to fetch GC1C8FF.
2. Placed date is in 1900.
3. GeoToad fails to convert this into a valid Unix date.

What is the expected output? What do you see instead?

Actually this shouldn't happen. Apparently there's no sanitizing being 
performed at gc.com

More error checking and handling is necessary in common.rb@

Please provide any additional infomation below.

Original issue reported on code.google.com by Steve8x8 on 31 Aug 2012 at 8:30

[GoogleCodeExporter]

Although (again :(() I'm unable to reproduce this problem under Debian Wheezy, 
I've come up with a patch that *might* fix the issue - Windows users, please 
apply, test, and report back!

--- old/common.rb   2012-06-06 16:03:34.000000000 +0200
+++ new/common.rb   2012-09-01 12:25:07.000000000 +0200
@@ -38,6 +38,8 @@
   def parseDate(date)
     debug "parsing date: [#{date}]"
     timestamp = nil
+    # catch exceptions in case there are invalid dates (like GC1C8FF)
+    begin
     # we have to overcome the ignorance of ruby1.8 wrt Unicode characters
     case date
     # relative dates end in a "*"
@@ -118,6 +120,10 @@
       displayWarning "Could not parse date: #{date}"
       return nil
     end
+    rescue => error
+      displayWarning "Error encountered: #{date} #{error}"
+      return nil
+    end
     if not timestamp and days_ago
       timestamp = Time.now - (days_ago * 3600 * 24)
     end

Original comment by Steve8x8 on 1 Sep 2012 at 10:32

• Changed title: Invalid dates crash GeoToad (Windows only?)

Attachments:

• 254-invalid_placed.diff

[GoogleCodeExporter]

Seems to be working on XP with Ruby 1.9.1

Search for "nearest" worked w/o any problem where it stopped before, 
downloading of caches still proceeding.   

Thanks for the quick response!

Original comment by GC.Womba...@gmail.com on 1 Sep 2012 at 4:44

[GoogleCodeExporter]

Please check whether the cache shows up in the resulting list, and if it does, 
how does the placed date (<groundspeak:date>) look like? I might have to fake 
something that's inside the valid ranges for Windows' and Unix' time but 
reasonably before geocaching started ($ZEROTIME = noon UTC Jan 1, 1980) if it's 
not already set to such a value.
If the cache doesn't show up at all, something worse is still wrong.

Original comment by Steve8x8 on 1 Sep 2012 at 7:05

[GoogleCodeExporter]

The cache showes up in results. The date of placement is todays date. 
(Originally it was published on 17.May 2008)

Thanks again
Wombat97

Original comment by GC.Womba...@gmail.com on 1 Sep 2012 at 8:20

[GoogleCodeExporter]

I guess "today" is not ideal (forcing frequent reloads) but it's probably the 
best we can do - or should it be dated back to the beginning of the Windows 
timescale instead?
Since the next release is still a bit away changes are still possible...
Nevertheless, the current patch has been merged into trunk now. Feedback is 
appreciated.

Original comment by Steve8x8 on 4 Sep 2012 at 8:21

• Changed state: FixAvail

[GoogleCodeExporter]

Issue is supposed to be addressed by the recent 3.16.2 release.

Original comment by Steve8x8 on 28 Sep 2012 at 11:27

• Changed state: Fixed