id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
90	timestamps: formatting and timezones	Zooko	Zooko	"Please use ISO-8601, except with ""_"" instead of ""T"" for the separating
character for all timestamps. Please include the ISO-8601 unambiguous
timezone indicator (which is either ""Z"" or a number of hours offset from UTC
-- I don't know what the standard is for non-integral offsets, but see
below).

Next, please consider using UTC times for all timestamps instead of
localtimes. Foolscap is system for remote computation, and the remote end may
or may not be in the same timezone as the local end, which may or may not be
in the same timezone as the programmer who is looking at it. A nice,
consistent simple way to deal with such things is just not worry as much
about how sunny the sky was, and who was awake, in the land where the server
lives and just use UTC for everything.

(More seriously, the trade-off is cognitive difficulty of correlating events
on a server from human-rhythm events that take place in the same timezone,
such as meals and sleeping, vs. the cognitive difficulty of correlating
events on a server with events on other computers. In my experience working
in distributed systems, I'm more frequently interested in the latter
correlations.)

Here is the related discussion from the Tahoe trac:

 * http://allmydata.org/trac/tahoe/ticket/326 # use consistent time stamps in logging

Here are some Python implementations of ISO and/or UTC timestamps:

 * http://allmydata.org/trac/tahoe/browser/src/allmydata/node.py?rev=2731#L30
 * http://allmydata.org/trac/tahoe/browser/src/allmydata/util/time_format.py?rev=2424#L12
 * http://allmydata.org/trac/pyutil/browser/pyutil/pyutil/time_format.py?rev=93
"	enhancement	closed	major	undecided	logging	0.3.0	fixed