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

["David W. Forslund" <dwf@lanl.gov>]

This sounds good to me.

Dave
At 05:05 PM 4/2/99 , Larry Hamel wrote:
>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
>