On Thu, Dec 2, 2010 at 1:06 PM, Kiran Ayyagari <[email protected]> wrote:
> On Thu, Dec 2, 2010 at 12:59 PM, Emmanuel Lecharny <[email protected]> > wrote: > > Hi guys, > > > > we currently don't use anything but the basic Java Date classes to > > manipulate dates in Kerberos. For instance, the KerberosTime data > structure > > is encapsulating a long, representing the number of seconds since jan, > 1st, > > 1970. But the problem is that it does it incorrectly, as the following > > constructor shows : > > > > /** The kerberosTime, as a long */ > > private long kerberosTime; > > ... > > /** > > * Creates a new instance of a KerberosTime object > > */ > > public KerberosTime() > > { > > kerberosTime = System.currentTimeMillis(); > > } > > > > The problem with this constructor is that it takes the local time, not > the > > UTC time, when the RFC states : > > > > "...As required by the DER, it further shall not include any separators, > and > > *it shall specify the UTC time zone* (Z)..." > > > > Getting the System.currentTimeMillis() value does not return an UTC. > > > > Now, using JodaTime won't solve the problem, but the Joda classes are way > > more simpler to use than the standard Java ones (up to a point the JSR > 310 > > is going to define a new Date API for JDK 8, based on the Joda API). > > > +1, sounds good to me > > +1 , maybe we can use this everywhere cuz even on the LDAP side some of the GeneralizedTime value generation was a bit shady with the JDK classes. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
