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
-- Kiran Ayyagari
