Foswiki on GitHub is open for business! Next release meeting: Monday October 13, 1300Z

Item753: Foswiki::Time::parseTime has a major parsing bug for some date formats

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Urgent Closed Engine    

all this is due to a search that uses

d2n(fields[name='Date'].value) >= d2n('2008/12/1') AND d2n(fields[name='Date'].value) <= d2n('2009/1/1')

and returns a topic that has a Date == '13 Oct 2008'

so here goes as an IF

  • IF{"d2n('13 Oct 2008') >= d2n('2008/12/1') AND d2n('13 Oct 2008') <= d2n('2009/1/1') " then="true" else="false"}
    • false broken in v1.0.0

  • IF{"d2n('13 Oct 2008') >= d2n('2008/12/1')" then="true" else="false"}
    • false broken in v1.0.0

  • IF{"d2n('13 Oct 2008') <= d2n('2009/1/1') " then="true" else="false"}
    • true

  • Set MYDATE = 13 Oct 2008
  • IF{"d2n('%MYDATE%') >= d2n('2008/12/1') AND d2n('%MYDATE%') <= d2n('2009/1/1') " then="true" else="false"}
    • false

variations on the broken bit?
  • IF{"d2n('2008/10/13') >= d2n('2008/12/1')" then="true" else="false"}
    • false
  • IF{"d2n('2008/10/13') > d2n('2008/12/1')" then="true" else="false"}
    • false
  • IF{"d2n('2008/10/13') = d2n('2008/12/1')" then="true" else="false"}
    • false
  • IF{"d2n('2008-10-13') = d2n('2008-12-1')" then="true" else="false"}
    • false System.TimeSpecifications tells me that . and / can be used instead of - in the YYYY-mm-dd form, but that appears to be untrue.

which all points towards a parse failure, which then returns a constant, giving us a non-helpful spurious match

as an obviously terminal case, the following should not really return 'true'
  • IF{"d2n('banana') = d2n('apple')" then="true" else="false"}
    • true

seems reasonable

  • IF{"d2n('1/Oct/2008') <= d2n('1/Nov/2008')" then="true" else="false"}
    • true

  • IF{"d2n('2008.10.1') <= d2n('1/Nov/2008')" then="true" else="false"}
    • false

  • IF{"d2n('2008-10-1') <= d2n('2008-11-1')" then="true" else="false"}
    • true

  • IF{"d2n('2008-12-1') <= d2n('2008-11-1')" then="true" else="false"}
    • false

  • IF{"d2n('2008.12.1') <= d2n('2008.11.1')" then="true" else="false"}
    • false

  • IF{"d2n('2008.12.1') <= d2n('1.11.2008')" then="true" else="false"}
    • false

  • IF{"d2n('1 Dec 2008') <= d2n('1 Nov 2008')" then="true" else="false"}
    • false

not so much (they should be FALSE)

  • IF{"d2n('1/Dec/2008') <= d2n('1/Nov/2008')" then="true" else="false"}
    • true

  • IF{"d2n('1-Dec-2008') <= d2n('1-Nov-2008')" then="true" else="false"}
    • false

  • IF{"d2n('Dec 2008') <= d2n('Nov 2008')" then="true" else="false"}
    • true

  • IF{"d2n('2009') <= d2n('2008')" then="true" else="false"}
    • false

other possible troubles %20 encoded space

ok
  • IF{"d2n('1%20Dec%202008') < d2n('1%20Nov%202008')" then="true" else="false"}
    • false
should be false?
  • IF{"d2n('1%20Dec%202008') > d2n('1%20Nov%202008')" then="true" else="false"}
    • false


i'm wondering if we should not have the IF d2n throw a red error if it doesn't successfully parse the date.. though tbh, i thought we supported the non-ambiguous 1-Jan-2009 form (seems i miss assumes the space, dot and dash would all work for this - space is working).

mmm, TimeSpecifications tells me that 31 Dec 2001 - 23:59 is ok

Proposed work to resolve

  1. fix the parse issue for "d2n('2008/10/13') = d2n('2008/12/1')"
    • FIXED
  2. add support for / - . etc to the 12 Jan 2009 form - so long as its not too hard to write enough unit tests.
    • REJECTED: its pretty hard to reliably know what 09 Dec or Dec 09 is with the current spec/docco -

moved additional works to Item769 as i can't justify putting them into 1.0.1

-- SvenDowideit - 15 Jan 2009

ItemTemplate edit

Summary Foswiki::Time::parseTime has a major parsing bug for some date formats
ReportedBy SvenDowideit
Codebase 1.0.0, trunk
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Engine
Component
Priority Urgent
CurrentState Closed
WaitingFor
Checkins distro:9c1e0954f0b6
TargetRelease patch
ReleasedIn 1.0.1
Topic revision: r5 - 23 Feb 2009, KennethLavrsen
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License