You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/12/02 11:59:49 UTC
Using Joda Time lib for date manipulations in Kerberos
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).
Any objection ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Using Joda Time lib for date manipulations in Kerberos
Posted by Alex Karasulu <ak...@apache.org>.
On Thu, Dec 2, 2010 at 1:06 PM, Kiran Ayyagari <ka...@apache.org> wrote:
> On Thu, Dec 2, 2010 at 12:59 PM, Emmanuel Lecharny <el...@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
Re: Using Joda Time lib for date manipulations in Kerberos
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Dec 2, 2010 at 12:59 PM, Emmanuel Lecharny <el...@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
--
Kiran Ayyagari