On Aug 16, 2007, at 2:19 AM, Scott Deboy wrote:
In TimestampInequalityRule and TimestampEqualityRule, we could
support a 2nd simpledateformat transparently, which would kick in
if the long format couldn't parse the argument.
The 2nd simpledateformat could be 'HH:mm:ss' - add the millis
representing the current day at midnight to those millis and use
that long in comparisons.
The one drawback is you couldn't make inequality comparisons across
midnight.
Just a thought. I coded it up and it was pretty straightforward
and worked well, but I'm not sure that's what we want to do. I'm
also not sure how we would tackle LikeRule.
Scott
I had originally thought of a derived class of Date (which implements
Comparable for the equality/inequality rules) and overrode toString()
to provide the XML Schema lexical rep (subset of ISO 8601) for the
LikeRule, but then saw that the inequality/equality rules did not use
Comparable but depended on toString() returning the string
representation of an integer, so the clean approach wouldn't work.
If you could expand the test suite, particularly around the TIMESTAMP
expressions, it would help regardless of what we want to try to do.
I don't think we can overload TIMESTAMP without endangering the
existing rules which ignore timezone et al.
You could break things into TIME, DATE and DATETIME where each would
have a long value space and an XML Schema lexical space for the like
operator.
It looks like the current implementation of LoggingEventFieldResolver
would be affected by the Turkish-i problem as it does a locale-
sensitive toUpperCase() in at least one place.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
