XXX: correct/remove a wrong analysis

apparently these output and the conclusions where done while the
prototype script had a "try: except: reuse variable from previous
iteration" error

prototype/README.md

@@ -61,41 +61,16 @@ no more errors reported.
 
 As we could see go and python have small differences, but it's OK.
 
-One problem is that it (especially python's dateparser) does not report errors on invalid input, but almost always parse something. It has  a `STRICT_PARSING` option, but it still allows invalid inputs (and BTW, this `STRICT_PARSING` seem to cause different behavior on some relative dates). With dateparser, basically when the output contains numbers, the parser will return a date ... that can be different from what user expected.
+One concern is that parsers might not report errors on invalid input, as they support a wide range of formats.
+dateparser has a `STRICT_PARSING` option, but it does not seem to be so effective after a very short test.
 
-for example with these inputs:
-```
-### some invalid formats that "looks OK"
-# wrong format on timezone (should be 2009-06-01T22:00:00+09:00)
-2009-06-01T01:00:00Z XXX 2009-06-01T10:00:00:+09:00
-# day is 34
-ERROR XXX 2009-06-34T22:00:00Z
-# one digits hour minutes
-ERROR XXX 2009-06-01T1:2:3
-# month use a captital o instead of O
-ERROR XXX 2009-O6-01T22:00:00Z
-```
-
-there's no error, just unexpected behaviors:
-```
-(env) $ python prototype/proto.py
-ERROR timespec: 2009-06-01T10:00:00:+09:00 expected time: 2009-06-01T01:00:00Z parsed time: 2009-06-07T04:00:00Z
-ERROR timespec: 2009-06-34T22:00:00Z expected time: ERROR parsed time: 2009-06-07T04:00:00Z
-ERROR timespec: 2009-06-01T1:2:3 expected time: ERROR parsed time: 2009-05-31T23:02:03Z
-ERROR timespec: 2009-O6-01T22:00:00Z expected time: ERROR parsed time: 2009-06-01T22:00:00Z
-(env) $ go run ./prototype/proto.go
-ERROR timespec: 2009-06-01T10:00:00:+09:00 expected time: 2009-06-01T01:00:00Z parsed time: 2009-08-30T08:00:00Z
-ERROR timespec: 2009-06-34T22:00:00Z expected time: ERROR parsed time: 2009-08-30T20:00:00Z
-ERROR timespec: 2009-06-01T1:2:3 expected time: ERROR parsed time: 2009-06-01T01:02:03Z
-ERROR timespec: 2009-O6-01T22:00:00Z expected time: ERROR parsed time: 2009-08-30T20:00:00Z
-```
 
-But with valid inputs, current implementations de-facto support many formats, so for users who don't read the manual, it seem the tool support "any format and it will magically work", but sometimes it will not do what they think.
+With valid inputs, current implementations de-facto support many formats, so for users who don't read the manual, it seem the tool support "any format and it will magically work", but sometimes it might not do what they think.
 
 The original need was to support using date in tidrange, without having to "calculate" the tid from hash.
 
 Relative dates are a cool feature, but I feel the most common use cases would be to use absolute dates.
-If we only supported only one simple format (ISO8601), we would be able to detect and refuse invalid inputs.
+If we only supported only one simple format (ISO8601), we would be able to reliably detect and refuse invalid inputs.
 
 That said, this is a tool for power users, so maybe that's OK as is. All these arguments exists for any powerful but dangerous tools such as using chainsaw to cut wood faster or cars to move faster, so maybe we should not worry here.