Why timestamp + timezone rather than date stamp

[John A Meinel]

Martin Pool wrote:

>On 30 Jun 2005, John A Meinel <john at arbash-meinel.com> wrote:
>
>
>>I'm just wondering why Revision entries store the local timestamp
>>(seconds since epoch) plus the local offset in seconds relative to GMT,
>>rather than either storing a datestamp or a GMT timestamp, and then some
>>information about what timezone it was committed in.
>>
>>
>
>I'm fairly sure it stores the GMT timestamp, as returned by time.time(),
>not the local timestamp.
>
>
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.
It just tells you what timezone it is in.

>Why store this in the XML, not a formatted time?  A couple of reasons:
>firstly it was just easier to write in the first place; secondly it's
>also easier to write for anyone redoing this in C.  It will be slightly
>slower to parse.  None of them are really compelling reasons.  I see the
>XML as primarily machine-readable,
>
>
>
>>If it was a resolution problem, the following code produces
>>high-resolution datestamps:
>>
>>def format_highres_date(t, offset):
>>   import time
>>   tt = time.gmtime(t + offset)
>>   return (time.strftime("%a %Y-%m-%d %H:%M:%S", tt)
>>           + ('%.9f' % (t - int(t)))[1:]
>>           + ' %+03d%02d' % (offset / 3600, (offset / 60) % 60))
>>
>>In my case, doing:
>>format_highres_date(time.time(), -time.altzone)
>>Returns
>>'Thu 2005-06-30 13:16:08.646850109 -0500'
>>
>>
>
>We should in any case probably switch to storing the fractional seconds
>as integer nanoseconds to avoid floating point inaccuracies.
>
>
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.

>I don't think there's much point in storing the day; and the timezone
>representation should probably be in a different xml field.
>
>
>
>>Which I think is pretty concise, and more understandable than the
>>equivalent:
>>
>>
>>>>>print 'timestamp="%.9f", timezone="%d"' % (time.time(), -time.altzone)
>>>>>
>>>>>
>>timestamp="1120155435.368813038", timezone="-18000"
>>
>>That timestamp is very hard to understand.
>>
>>
>
>Right, but that should only be a problem for people looking directly at
>the XML, so I don't see why it's a big deal?  I don't really object to
>switching though.
>
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.
John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050630/f45705f8/attachment.pgp