Why timestamp + timezone rather than date stamp

[Martin Pool]

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
> seconds.

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?

-- 
Martin