Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
Attachments:
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
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
3.19.2 has been just released, addressing this issue (among others).
Original comment by Steve8x8
on 6 Jan 2014 at 1:50
Original issue reported on code.google.com by
pokorny....@gmail.com
on 27 Dec 2013 at 9:55