[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [Syntaxes] Century overflow in Generalized Time
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
>