[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: possible bug

From: Andy Cutright <Andy.Cutright_at_borland.com>
Date: 2005-06-28 18:29:48 CEST

i've found the point in the java code where i believe the value is being
truncated. guess i'll have to look around to find an appropriate
solution. i'll file a bug as well. i realize the Date class isn't
designed to resolve microseconds, but this truncation isn't really
helpful :) thanks for the help,

cheers,
andy

> -----Original Message-----
> From: Philip Martin [mailto:philip@codematters.co.uk]
> Sent: Monday, June 27, 2005 4:43 PM
> To: Andy Cutright
> Cc: Greg Hudson; dev@subversion.tigris.org
> Subject: Re: possible bug
>
> "Andy Cutright" <Andy.Cutright@borland.com> writes:
>
> > the time stamp i get back from the client libraries is a long,
> > representing milliseconds since the epoch, so supposedly i've got a
> > window of milliseconds, i believe. please correct me if i'm wrong.
>
> A long? Which libraries?
>
> I don't really do Java, but as far as I can tell the javhl bindings
> use Date, see org.tigris.subversion.javahl/LogMessage.java. Goggle
> tells me that Java's Date is in milliseconds so the javahl bindings
> don't return the full timestamp.
>
> > i do hear what you're saying about multiple commits
> potentially making
> > the timestamp a weak key.
> >
> > should i file a bug then?
>
> On Java perhaps :) Does Java have a time/date class that represents
> microseconds? If not then the bindings would need to use something
> other than, or in addition to, the native Java type.
>
> --
> Philip Martin
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 28 18:38:00 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.