Capistrano should get the release date from the remote system. about capistrano HOT 3 CLOSED

You probably need to make sure that clocks are synchronized on all systems you work with.

Thanks to ntp and openntpd, this should be a very simple undertaking nowadays.

If capistrano reads remote server time, how should it behave in a situation like the following:

• There are servers A, B and C, all out of sync time-wise
• Command X is run on servers A and B
• Then, command Y is run on servers B and C

If capistrano read time from the first server, for example, in this case A for X, then by the time Y is run the time would be entirely different anyway.

from capistrano.

I discovered this bug because ntp died and the clock was off by several hours on a Jenkins slave. It's a VM, so it happens some times.

I was assuming that if you talked to multiple servers then it would get the time from each server and use that for the commands on each server. Using something like an environmental variable.

At the very least, it makes the concept of 'last' and 'current' suspect, since the timestamps can't be guaranteed to always going forward.

If figuring out which clock is accurate or using the server's clock isn't feasible, you could at least scan the existing timestamps and ensure that the new timestamp is greater than any of the existing ones (across all servers).

Ciao!

from capistrano.

@docwhat I think it's a standard part of keeping a good house to make sure your clocks are in sync.

Operating in local timezones on remote servers in UTC not withstanding, I'm not sure this is a Capistrano problem, I look forward to a patch though.

from capistrano.