On 07 Sep 2011, at 12:38, Frank Shearar wrote:
On 7 September 2011 10:52, Andy Kellens <akellens@vub.ac.be> wrote:
Hello,
While working here with Veronica on importing the history of Ring, I found some strange behaviour in Monticello. Veronica and Stéphane were working on Ring at CAMP Smalltalk in Edinburgh; Stéphane already changed his time zone to GMT time; Veronica did not.
As a result, there is a commit of a package from Stéphane at 6pm that has as an ancestor a package from Veronica at 7pm. It looks like Monticello uses the timestamp of the computer from which the package was published; not the timestamp from the computer. Given that people are working on the same code from all across the world, this can be a bit counter-intuitive.
Shouldn't Monticello use the timestamp from the server?
What's a server, though? My computer? Your computer? Some shared repository (which is really just another peer)?
What if I commit one version to my local package cache, daylight savings starts (or ends - I can never remember which makes the clock go back), and I commit a new version. Hey presto, the new version has a timestamp older than the old version.
The answer is this: don't look at the timestamp; it's irrelevant. Look at the ancestry of the package.
The motivation of using the timestamp is that we are computing dependencies between packages. Sure, in the case that you have a Metacello configuration, or you use slices, it is fairly easy to see which versions of packages go together. However, if you do not have this information, timestamps seem to be the only thing you can rely on. Actually, we were able to pin down the problem: it is not an issue of Monticello at all but rather an issue related to how time zones are handled in Pharo. Pharo appears to set the local time zone when opening the image; if you are traveling with an image open (what Veronica did), change time zones, and continue to work, then your TimeStamps are not aware of the fact that you changed time zones. This made me wonder: what is the reason for keeping track of the current time zone within the image, and not just relying on the computer's time when calculating DateAndTime now? There is a primitive that asks for the local time zone.
frank
Kind regards,
Andy