On 11/08/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > i would agree with you there, this is where a more robust (ie: > less efficient) DateField-ish class that supports configuration options > to specify: > 1) the output format > 2) the input format(s) > 3) the indexed format > ...as SimpleDateFormatter pattern strings would be handy. The > ValueSource it uses could return seconds (or some other unit based on > another config option) since epoch as the intValue.
That definitely sounds like a sensible and flexible approach, I'll have to take a closer look at the ValueSource and FunctionQuery classes and see what I can come up with. it's been discussed before, but there are a lot of tricky issues involved > which is probably why no one has really tackled it. It does seem somehow related to the issue of making the value of NOW constant during the entire execution of a query, hopefully not in the to-hard basket. be careful what you wish for. you are 100% correct that functions using > hte (r)ord value of a DateField aren't a function of true age, but > dependong on how you look at it that may be better then using the real age > (i think so anyway). I understand the problems you describe with using true age values, although I wonder how much recip() (or perhaps some other logarithmic function) would be able to dampen any unpleasant side-effects created by unusual publishing patterns, not publishing on weekends, etc. Using "min age" sounds like a much better idea than using NOW to avoid any of the described weirdness too, but that might increase the complexity of the function. I'm still keen to get something working, at least to compare the results it generates with the current ordinal method. Piete
