Why timestamp + timezone rather than date stamp
mbp at sourcefrog.net
Fri Jul 1 06:03:50 BST 2005
On 30 Jun 2005, John A Meinel <john at arbash-meinel.com> wrote:
> In commit.py it says:
> if timestamp == Nnoe:
> timestamp = time.time()
> if timezone == None:
> timezone = local_time_offset()
> rev = Revision(timestamp=timestamp,
> And then in revision.py it uses:
> root = Element('revision',
> timestamp = '%.9f' % self.timestamp,
> if self.timezone:
> root.set('timezone', str(self.timezone))
> Which means that nowhere does it convert the local timestamp into GMT.
time.time() "returns the time as a floating point number expressed in
seconds since the epoch, in UTC."
> So your intent was that the %.9f was going to return nanoseconds? No
> problem. But your time resolution is *far* worse than that.
> I think we would be absolutely fine with a timestamp that was limited to
Humans are rarely going to care about precision of less than a second,
but since the system give it to us I think it's useful to store it. It
might be useful in, for example, branches generated by scripted systems
that generate multiple commits per second.
> It isn't a big deal. I *do* look at the xml from time to time, and it is
> pretty meaningless without having a computer interpret it for you.
> As you say, it is probably easier to re-create as timestamp + timezone
> since they are simple numbers. I don't think we need sub-millisecond (I
> don't think we really need sub second).
> If you look at my earlier tests, it looks like 10us is a decent cutoff
> point to get stable floating point precision.
Perhaps we should make it 6 decimals (microseconds) and be done?
More information about the bazaar