Reviewing the docs to catch up with post-1.0.5 changes, I stumbled into 
the best-practices chapter, and have to disagree on a single aspect.

Slony-I is a tool that's added to arbitrary databases, which are used by 
apps that might require strange settings to work. This means, that a 
system tool should have as few dependencies on settings as possible.

In general, to avoid any conversion problems it's best practice to a use 
data types that are independent on locale/tz settings. These settings 
only describe the formatting of the data, but tend to make the data less 
easily interpretable; thus it's desirable to use data that's as raw as 
possible, unless it's necessary to display it to a human.

Currently, there's at least at one occurrence (AFAICS it *is* the only 
one) where Slony is violating this principle. For no obvious reason, 
sl_confirm.con_timestamp uses timeofday()::timestamp instead of now(), 
which requires date formatting (dependent on clib/whatever formatting 
facilities), and interpreting that string data, instead of using a 
function that already delivers the required type. This is easily 
fixable, and I don't see a reason not to do this. It would make Slony 
more independent of settings, thus more widely usable.

Having all machine's clocks in time sync is a requirement of slony that 
seems quite obvious. Still, if this requirement is not met for whatever 
reason (maybe an admin is 110 % sure ntpd is running, but it stalled), 
things might get screwed up in a way that's not easy to debug.
After a brief look at slon, it seems that local time is used for 
checking timeouts only (the only insert into a timestamp column uses 
now()), so problems from clock drift are unlikely to appear from that. 
But databases servers still might deviate, how about a check in slon 
that checks regularly if the servers in use are sufficiently in sync? 
Maybe slon should even refuse to run/stop working if server clocks 
(checked with now(), not timeofday()) are not sufficiently in-sync.

Regards,
Andreas