[patch] commit timestamp incorrectly cast if specified

[Martin Pool]

On 17 Jan 2006, John A Meinel <john at arbash-meinel.com> wrote:
> Denys Duchier wrote:
> > John A Meinel <john at arbash-meinel.com> writes:
> > 
> >> I agree. I'm not sure why we would have used long(), maybe it makes the
> >> test suite easier to run.
> > 
> > Hashcache uses int(time.time()) to loose precision on purpose so that timestamps
> > can be (more) safely distinguished.  If there was a similar reason at work here,
> > then the "else:" should be removed.
> > 
> > --Denys
> 
> I'm not sure why we would need higher resolution than 1s for a revision
> entry. I would be okay with dropping the sub-second resolution, since it
> doesn't really mean anything anyway.

Storing it as a float is not so good because there is some possibility
of introducing errors as we go to and from a decimal ascii
representation.  It can be avoided with care but I'm not sure subsecond
precision is really needed or very useful.

I'll look at pulling in the tests from Jamie's patch.

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060118/926bd6ac/attachment.pgp