Subject: Re: [Syntaxes] Century overflow in Generalized Time

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 17 Jun 2003 09:56:45 -0600

I've always thought of these as "known limitations"

>>> Hallvard B Furuseth <[email-masked]> 6/17/03 7:18:44 AM
>>>
John McMeeking writes:
> Generalized time uses a 4-digit year (YYYYMMDD...) .  Wrap-around
won't
> occur until date reach the year 10000 (another 7997 years to go).

So?  Someone may still put dates far in the future (or the past) in
the
directory, or compare with such dates.

Come to think of it, another gray area is dates from before the
Gregorian calendar was used.  But that's so messy that I don't know
what
to suggest, except possibly that implementations _may_ be clever about
that if they want to.  Like not having leap years before 1581 or
whatever, and implementing the 'hole' in the calendar that year where
some days were skipped when comparing dates with different time zones
(where the hour may overflow into the hole).

-- 
Hallvard

---

From: John McMeeking <[email-masked]>
Date: Wed, 18 Jun 2003 10:04:59 -0500

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                                                                                    
                      <[email-masked]        To:       [email-masked]                                        
                      io.no>                      cc:       [email-masked]                                        
                      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