RE: [Syntaxes] Century overflow in Generalized Time

["Steven Legg" <steven.legg@adacel.com.au>]

Hallvard,

Hallvard B Furuseth wrote:
> How is century overflow/underflow in Generalized Time handled?

The matching semantics are described in terms of the underlying
universal coordinated time represented by the character string.
Underflow/overflow is meaningless in that context. Matching rule
evaluation functions are not restricted to what can be physically
represented in the syntax.

> That is,
> - does generalizedTimeMatch say 9999123120-08 = 0000010104Z?

The first string represents the UTC date & time 04:00 on the 1st of
January 10000. The second string represents the UTC date & time
04:00 on the 1st of January, year 0. The former is clearly greater
than the latter.

> - how does generalizedTimeOrderingMatch order 9999123120-08
>   vs. 2000010100Z?

The former is greater than the latter by the same reasoning.

> 
> I suggest to leave it implementation-defined as long as the 
> two matching
> rules are consistent, and maybe allow (but not require) such 
> dates to be
> invalid.
> 
> But if the draft does specify a rule, I think the rule should 
> be silent
> wraparound (i.e. century 0 = -100 = +100), since these centuries would
> all look the same when expressed as a Generalized Time date.

GeneralizedTime has a limited range of dates it can represent.
Dates outside that range cannot be represented. End of story.
It is analogous to an INTEGER that is constrained to be between
0 and 9. Integer values outside the range cannot be represented,
but we can still perform arithmetic on a much wider range of
integer values.

Regards,
Steven

> 
> -- 
> Hallvard
>