• an HistoricizedSearch would show results in a topic as of a date specified somehow. this topic would be, as far as I can judge, classified as FeatureEnhancementRequest or FeatureBrainstorming, and be in SpecProgress about 25%.

what follows it the list of comments added in the topic SearchByDate, where all parts relative to that interpretation have been removed, by MarioFrasca.

I need to be able to search on which bugs were closed between date1 and date2

to this end i have started to look at adding a date attribute to SEARCH anf METASEARCH. however this will require re-doing the Search.pm code so that it goes through the Store.pm interface (not a bad thing, but slower, and a bit of work...)

-- SvenDowideit - 26 Feb 2003

Instead of tweaking Search.pm alone -- how about a Wiki:WayBackMode, which covers all storage access? E.g. setting a cutoff date to the RCS calls. Other areas, most notably dynamic pages with %INCLUDEs and normal %SEARCHes could benefit as well.

Ah -- doesn't solve Sven's specific need: a range of dates. Hmm. That's probably really specific to (a few) %SEARCHes.

-- PeterKlausner - 26 Feb 2003

I have noticed the IncludeRevisionPlugin which contains most of the work necessary to view topics by date rather than revision. Peter - can we add this to the twiki code? If you say yes, i'll make the changes needed to generalise it and upload them

then all i need to do is change search to request a particular date's version of the topic (with empty topics if they don't exist)

-- SvenDowideit - 07 Mar 2003

(Breaking your edit lock before the time is up...)

Yes, a search trip back in time would be a usfull addition! Probably with a date="2003/03/07 04:32+00" parameter to SEARCH. A man co reports that these date formats are possible:

    8:00 pm lt
    4:00 AM, Jan. 12, 1990           default is UTC
    1990-01-12 04:00:00+00           ISO 8601 (UTC)
    1990-01-11 20:00:00-08           ISO 8601 (local time)
    1990/01/12 04:00:00              traditional RCS format
    Thu Jan 11 20:00:00 1990 LT      output of ctime(3) + LT
    Thu Jan 11 20:00:00 PST 1990     output of date(1)
    Fri Jan 12 04:00:00 GMT 1990
    Thu, 11 Jan 1990 20:00:00 -0800  Internet RFC 822
    12-January-1990, 04:00 WET

Question is what TWiki should support, e.g. what to document and what to implement in the RcsLite.

-- PeterThoeny - 07 Mar 2003

I came across this topic looking just for this feature: a date="2003-03-07 04:32+00" parameter to SEARCH. I would suggest the ISO format with a 'T' instead of a ' ' to separate the date from the time. in this form ISO does the case for a time interval. you have to get used to it a bit. you can refer to http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html, in particular the last section handles periods of time.

-- MarioFrasca - 16 Dec 2003

I do this kind of stuff in the ActionTrackerPlugin; see ActionNotify.pm, _findChangesInWebs and _getRevAtDate. The comments note a code smell, because it uses an 'rlog' to query the topic history, which is something that the Store module should, but does not, provide. This is what makes the action tracker incompatible with rcsLite. When you are fixing this, please make sure the appropriate functionality gets into Store! Please! Oh, and publish it via the Plugins interface, too. Pretty please!!!!

-- CrawfordCurrie - 16 Dec 2003

(I'll look into adding the rlog interface to StoreDotPm for CairoRelease, but the remainder will need to wait til there is more time

-- SvenDowideit - 16 Dec 2003

to attempt to make my requirement clearer:-

I would like to view the state of the CairoRelease topic on the date of the last beta. this requires the twiki to be able to use the rcs info to not only show that version of the CairoRelease topic, but also to do the SEARCHES based on the topics that were in existance then, and their state at that time. (that way i can then do a diff between the progress table between the last BetaRelease and today.)

-- SvenDowideit - 16 Jan 2004

hoi Sven, ach, probably I understand. I'll state what you say differently, just to make sure we talk about the same feature. you are talking about only one topic, so what is the sense of searching? ah, yes, because in that topic you have a SEARCH, and its result is computed dynamically. so when you look at that topic as of a specific date, say one year ago, the html page you receive today is not the same you would have read one year ago, nor can you be sure it is the same you will read tomorrow. that is a problem and I now see why you need to look into rcs files.

maybe my feature could be renamed from date to timeframe. or possibly yours from date to frozenatdate. or even you could think that a SEARCH must be frozenatdateofversion, maybe this could be a boolean option. when you ask for a specific version of a topic and this contains a SEARCH, the date of the container topic is then passed to the searchWeb function. . . . there are some subtleties I don't understand.

When you look at the topic as of its current version, you want the state as of today, not as of the date of the current version. so what would you expect when you look at the same version of the topic over one year? you don't want the state as of the date of the version... this is not the result it would give when it was current. maybe you would associate a version to its last validity date, that is: the date of the following version - or today for the current version of the topic. I'm not sure, it looks to me a difficult task. also: how do you represent the results? if you give a link to any topics found, it would contain its version number. maybe the feature could be named 'historicized'...

-- MarioFrasca - 21 Jan 2004

Sven, just a thought... what about adding a today parameter to the url... then one would specify which date should be considered as the current date. and all things which came after that date are "simply" considered as not written. no idea of what consequences this may have, it also seems a difficult task, but: would it solve your problem?

-- MarioFrasca - 24 Sep 2004