[COAS-List] ISO timestamp: add wildcard char?

[Larry Hamel <larryh@medgrid.philips.com>]

Dave, Jay,

thanks for the feedback.

>If you adopt the string format, though, I think it
>means you need some other mechanism to handle the wild-carding

for the sake of clarity, let me define "wildcards" as encompasing two
concepts: the idea of (*input*) parameters (DONT_CARE), and the idea of
returning a timestamp (*output*) with some items unknown (DONT_KNOW).

ISO 8601 provides a limited form of wildcards, as in a date without time
("1999-04-02") or a year only ("1999"), or any date at 4pm ("16:00:00Z").

also, the standard provides another technique for wildcards as in a day
without a year and month in "---DD".  However, this "wildcard by hyphen"
technique is not 100% allowed in the "extended" form with delimiters.  

(BTW, extended form has delimiters like "1999-04-02", basic form without
like "19990402"; since delimters are a Good Thing for parsing, and required
by libraries like java.sql.Timestamp, i think that we should pin COAS to
require the extended form of ISO 8601.)

so there is a limited provision for wildcard values, although all wildcards
must be on "one side" of a TimeStamp.  the problem is when the wildcard
values are desired in the *middle* of a timestamp, as in as in
"1999-??-02T22:00:00Z" which would be equivalent to "the 2nd day of any
month in 1999, at 22:00:00 GMT".

how important having wildcards in the *middle* of a timestamp, as opposed
to the limited provision already provided by the standard?  

is the addition of a wildcard character "?" as in the example
"1999-??-02T22:00:00Z" sufficient and necessary?  

one disadvantage of a DONT_CARE (input) wildcard char is that it could be
substituted instead of EARLIEST_TIME or LATEST_TIME for an open-ended
timespan, and thus require more parsing.  i suppose documentation could
make this disadvantage clear, e.g.

	for searching, TimeSpan("????-??-??", "????-??-??") is less efficient
	than TimeSpan( EARLIEST_TIME, LATEST_TIME ).
	
recall that:
	const string EARLIEST_TIME 	= "1582-10-15T00:00:00Z" 
	const string LATEST_TIME 	= "9999-12-31T23:59:59Z"


> If you adopt the string format, though, I think it
>means you need some other mechanism to handle ... open
>ended time intervals (such as a logical element) for TimeSpan. 
>

maybe i'm missing something, but it seems to me that ISO 8601 can handle
"open-ended time intervals". an open-ended period could be defined with
EARLIEST_TIME as the start time, or with LATEST_TIME as the end time. 

note: i suggest that we do NOT use the ISO 8601 period definition with a
slash "/" between two stamps, all housed within the same string; better to
save some parsing and make it crystal clear what the two stamps are, within
the current TimeSpan struct:

	struct TimeSpan 
	{
		TimeStamp start_time;
		TimeStamp stop_time;
	};

larry