On Thu, Dec 2, 2010 at 1:06 PM, Kiran Ayyagari <kayyagari@apache.org> wrote:
On Thu, Dec 2, 2010 at 12:59 PM, Emmanuel Lecharny <elecharny@gmail.com> 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