Why timestamp + timezone rather than date stamp

[Martin Pool]

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.

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.

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.

-- 
Martin