Creation date parsing failed (for some date representation only)

[GoogleCodeExporter]

What steps will reproduce the problem?
geotoad.rb --cacheType='traditional|multicache|virtual|earthcache' 
--delimiter='|' --difficultyMax=3 --difficultyMin=1 --distanceMax=2 
--output='/home/petrp/temp/jinonice.gpx' --queryType=coord --terrainMax=4 
--terrainMin=1 'N50 2.836 E14 21.973'

What is the expected output? What do you see instead?
expected is file /home/petrp/temp/jinonice.gpx with caches in the area, instead 
it fails with
( - ) Output filename: /home/petrp/temp/jinonice.gpx
 ***  Problem (undefined method `strftime' for nil:NilClass) while converting cache GCZ38X:
{"distance"=>1.0, "direction"=>"E", "favorites"=>70, "fulltype"=>"Traditional 
Cache", "type"=>"traditional", "archived"=>false, "disabled"=>false, 
"name"=>"Nad Jezirkem", "creator"=>"Sekol_42 and Str8z, adopted by Tomas99", 
"country"=>"Czech Republic", "state"=>"Hlavni mesto Praha", 
"membersonly"=>true, "difficulty"=>2.5, "terrain"=>4, "dtsv"=>"not_encoded", 
"dts"=>"", "size"=>"small", "mtime"=>2013-11-28 00:00:00 +0100, "mdays"=>29, 
"adays"=>-1, "atime"=>1980-01-01 13:00:00 +0100, "visitors"=>[], "index"=>44, 
"guid"=>"8f70bee4-f205-4578-8772-018d3285a20a", "creator_id"=>2068551622, 
"shortdesc"=>"", "longdesc"=>"", "funfactor"=>0, "favfactor"=>0, 
"url"=>"http://www.geocaching.com/geocache/GCZ38X", "warning"=>"You must be a 
Premium Member to view this page.", "sname"=>"GCZ38X"}
ERROR: Backtrace: ["/home/petrp/temp/geotoad-3.19.1/lib/output.rb:1217:in 
`createExtraVariablesForWid'", 
"/home/petrp/temp/geotoad-3.19.1/lib/output.rb:1315:in `block in 
generateOutput'", "/home/petrp/temp/geotoad-3.19.1/lib/output.rb:1301:in 
`each'", "/home/petrp/temp/geotoad-3.19.1/lib/output.rb:1301:in 
`generateOutput'", "/home/petrp/temp/geotoad-3.19.1/lib/output.rb:429:in 
`prepare'", "./geotoad.rb:981:in `block in saveFile'", "./geotoad.rb:955:in 
`each'", "./geotoad.rb:955:in `saveFile'", "./geotoad.rb:1049:in `<main>'"]

What version of the product are you using? On what operating system?
geotoad-3.19.1, Linux 3.10.24-1, ruby 2.0.0p353

Please provide any additional information below.
The problem seems to be caused by only a dew caches which can't be parsed 
properly, I managed to export other area the other day sucessully.
The problematic caches are GCZ38X, GC3YFBB

There are also minor error messages like
[##%] (96/99) Read: [GC25FTC] "Maticka Zeme – Mother Earth" from local 
 ***  Could not convert timestamp '' to Time object.

Original issue reported on code.google.com by pokorny....@gmail.com on 27 Dec 2013 at 9:55

[GoogleCodeExporter]

While I'm trying to reproduce: What are your language and date format settings 
at gc.com? There might still be a hidden quirk only affecting some date 
representations and languages... (GeoToad should have reported the date format 
right after logging in. The language selected would only be shown in debugging 
output.)
GCZ38X and GC3YFBB are member-only caches (as a quick "-q wid" search shows), 
and the information available for them may be represented in a different way. 
3.19.2 will have a TUI option to suppress PMOs

Original comment by Steve8x8 on 27 Dec 2013 at 10:27

• Changed state: InfoNeeded

[GoogleCodeExporter]

I found this in the debug output:
D: setting selected option ctl00$ContentBody$uxLanguagePreference=en-US 
(English)
D: setting selected option ctl00$ContentBody$uxTimeZone=1 (GMT Greenwich Mean 
Time)
D: setting selected option ctl00$ContentBody$uxDateTimeFormat=dd/MMM/yyyy ( 
28/Dec/2013)
D: setting selected option ctl00$ContentBody$uxInstantMessengerProvider=0 (None)
D: setting selected option ctl00$ContentBody$ddlGPXVersion=1 (GPX 1.0)
( - ) Using date format dd/MMM/yyyy

Just realized there is -O option to exlude premium changes. That might solve 
the problem for me as I don't have premimum membership, will give it a try.

Original comment by pokorny....@gmail.com on 28 Dec 2013 at 8:37

[GoogleCodeExporter]

Confirming that option -O fixes "undefined method `strftime' for nil:NilClass" 
problem for me. I still have the "***  Could not convert timestamp '' to Time 
object." warnings (for each cache it's handling) but that doesn't seems to 
cause any troubles.

Original comment by pokorny....@gmail.com on 28 Dec 2013 at 8:40

[GoogleCodeExporter]

Strange - I haven't been able to reproduce this even after switching to Czech 
(but leaving the date format at the ISO setting yyyy-mm-dd which seems to be 
the only unambiguous one). I even reduced the search area to 50.042,14.388 
(with radius 0.25km).

Under some (obviously very rare) circumstances, in particular after switching 
preferences with some files still in the cache following the old style, this 
can happen - but it shouldn't. I guess I have to add some more sanitizing. 
Missing dates are a nuisance but shouldn't break everything - why there is no 
creation date is still a mystery to me.

Since you're not using the Windows package, the --noPMO command line option is 
certainly a workaround - but not a fix.
Since you also have debug output at hand: can you please lookup the line

D: found type=Traditional Cache wid=GCZ38X name=Nad Jezirkem

and check for everything below with "date:" in it, before the "end of row" line?
Something seems to be different between my and your results here.

Last-second edit: Found it. dd/MMM/yyyy date format was not completely parsed - 
everything else should work. Apperently there have been modifications to the 
format choices, or I just overlooked one date representation... grmbl.
(I still recommend the yyyy-MM-dd one because it can be sorted properly).

Fixing and testing now (it's a small patch, but this time I want to make sure 
all possible choices are covered). Thanks for your patience!

Original comment by Steve8x8 on 28 Dec 2013 at 9:49

• Changed title: Creation date parsing failed - Problem (undefined method `strftime' for nil:NilClass) while converting cache
• Changed state: Started

Attachments:

• 294-date_format.diff

[GoogleCodeExporter]

Checked the list of possible date formats with gc.com, and adjusted the 
patterns for creation time (in lib/search.rb) accordingly. Confirmation by OP 
pending, but I'm no longer able to reproduce the issue with his settings,

Original comment by Steve8x8 on 29 Dec 2013 at 5:49

• Changed state: FixAvail

[GoogleCodeExporter]

The OP, in personal communication, has confirmed that the patch cured his 
problems - after cleaning up in his .geotoad directory. One should always keep 
in mind that files are cached (below there) for several days - which makes 
changes not immediately visible. In particular, the "preferences" get stored 
for a couple of hours, and the cache description files will be replaced after 6 
days. While GeoToad makes some attempts to recover from "bad" (non-matching the 
prefs) date representations, in some places it can only guess...

Original comment by Steve8x8 on 6 Jan 2014 at 10:50

• Changed title: Creation date parsing failed (for some date representation only)

[GoogleCodeExporter]

3.19.2 has been just released, addressing this issue (among others).

Original comment by Steve8x8 on 6 Jan 2014 at 1:50

• Changed state: Fixed