I wouldn't go that far. You cannot compare dates if one of the values
normalizes to an illegal value (year > 9999 or year < 0). Other dates are
fine.
I think it would be reasonable for a server to reject a value like
9999123120-08 as an illegal value precisely because the normalized value is
illegal.
If an application wants to use such a "large" time, it should ensure that
normalized values stay within range -- Either don't use UTC offsets or use
a smaller time 99990101000000Z.
John McMeeking
Hallvard B Furuseth
<h.b.furuseth@usit.u To: steven.legg@adacel.com.au
io.no> cc: ietf-ldapbis@OpenLDAP.org
Sent by: Subject: RE: [Syntaxes] Century overflow in Generalized Time
owner-ietf-ldapbis@O
penLDAP.org
06/18/2003 08:36 AM
Steven Legg writes:
>> - does generalizedTimeMatch say 9999123120-08 = 0000010104Z?
>
> The first string represents the UTC date & time 04:00 on the 1st of
> January 10000.
Damn. Then we can't compare two dates by 'normalizing' them to
'Z' format and comparing the result:-(
--
Hallvard